DevOps实践指南 Gene Kim Jez Humble Patrick Debois John Willis ◆ 导言：展望DevOps新世界 >> 技术债务是指我们当前所做出的决定会导致一些问题，而这些问题随着时间的推移会越来越难解决 >> “三步工作法”的原则：流动、反馈和持续学习与实验。 ◆ 第一部分 DevOps介绍 >> 精益的两个主要原则包括：坚信前置时间（把原材料转换为成品所需的时间）是提升质量、客户满意度和员工幸福感的最佳度量指标之一；小批量任务的交付是缩短前置时间的一个关键因素。 >> 在敏捷宣言中，一个重要的原则是“频繁地交付可工作的软件，交付周期可以是数星期也可以是数月，推荐更短的周期”，并强调使用小批量任务进行增量发布 ◆ 第1章 敏捷、持续交付和三步法 >> 把价值流定义为“一个组织基于客户的需求所执行的一系列有序的交付活动”，或者是“为了给客户设计、生产和提供产品或服务所需从事的一系列活动，它包含了信息流和物料流的双重价值”。 >> 在DevOps中，我们通常将技术价值流定义为“把业务构想转化为向客户交付价值的、由技术驱动的服务所需要的流程”。 >> 应用程序或服务只有在生产环境中按预期正常地运行，并为客户提供服务，所有的工作才产生价值。所以，我们不但要快速地交付，同时还要保证部署工作不会产生混乱和破坏，如中断客户服务、性能下降或者信息安全不合规等问题。 >> 价值流始于工程师注1（包括开发、QA、IT运维和信息安全人员）向版本控制系统中提交了一个变更，止于变更成功地在生产环境中运行，为客户提供价值，并生成有效的反馈和监控信息。 >> 在第一个阶段中，工作主要包括设计和开发 >> 在第二个阶段中，工作主要包括测试和运维 >> 通过加快技术价值流的流速，缩短满足内部或者外部客户需求所需的前置时间，尤其是缩短代码部署到生产环境所需的时间 >> 通过放大反馈环防止问题复发，并能缩短问题检测周期，实现快速修复。 ◆ 第2章 第一步：流动原则 >> 可视化工作板是一种较好的工作方式，如在看板或Sprint计划板上，使用纸质或电子卡片将各项工作展示出来。 >> 多任务会导致更长的处理时间。 >> 将测试工作的在制品数量上限设置为3。当测试队列中已有3张卡片时，除非某张卡片完成了，或将3张中的一张退回到前一个队列（左侧的那一列），否则禁止添加新卡片。 >> 对于大多数的工作条目而言，在它们完成以前，其实并无法预测到底需要多长时间。 >> 停止开始，开始结束。 >> “大规模生产” -> 首先要将10张纸全都折叠完，再将每张纸分别插入信封，然后给所有的信封封口，最后全部盖章。 >> 小批量策略（即“单件流”）-> 对每本宣传册顺序地执行所需的所有步骤，然后再开始处理下一本宣传册。换句话说，先折叠一张纸，将其插入信封，再给信封封口，之后盖章；然后，取下一张纸，并重复以上过程。 >> 使用小批量策略时，仅用40秒就完成了第一封盖戳信的生产，比大批量策略快8倍。如果第一步出错了，只需要返工一本小册子。小批量生产的在制品更少，前置时间更短，错误检测更快，返工量更少。 >> 生产环境的变更越大，问题的定位和修复就越困难，修复时间也就越长。 >> 为了减少这类问题的出现，要么努力减少交接次数，要么用自动化方式执行大部分操作，要么重新调整组织结构，让团队不必依赖其他人就可以独立地为客户提供价值。 >> 要通过减少队列中的等待时间以及非增值工作的时间来增加流动性 >> 为了缩短前置时间、提高吞吐量，我们需要不断地识别系统中的约束点，提高工作产能。 >> 如果架构是紧密耦合的，那也无法实现按需部署，因为每次要做代码变更时，工程师都不得不从变更评审委员会里获得执行变更的许可。解决措施是创建松散耦合的架构 >> 提升技术价值流的流动性对实施DevOps来说至关重要。为此，我们需要将工作可视化，限制在制品数，减小批量大小，减少交接次数，持续地识别和改进约束点，以及消除日常工作中的困境。 ◆ 第3章 第二步：反馈原则 >> 在安灯绳被拉动时，团队领导就能第一时间得知并立即着手解决问题。如果问题不能在指定的时间（如55秒）内解决，就会停掉整个生产线，调动整个企业一起协作，直到成功地找出解决问题的对策。我们不应绕开问题，也不应该用“有更多时间时再解决”来搪塞 >> 群策群力的原因如下： ❏ 防止把问题带入下游的处理环节，否则不但修复的成本和工作量会呈指数级增加，而且还会欠下技术债； ❏ 防止工作中心启动新的工作，那样可能会在系统中引入新的错误； ❏ 如果问题还没有得到解决，那么工作中心在下一次操作（如55秒后）中，可能还会遇到相同的问题，需要更高的修复成本（见附录6）。 >> 循环（即PDCA环）——计划（Plan）、实施（Do）、检查（Check）、改进（Act） >> 精益定义了我们必须为两类客户而设计：外部客户（最有可能为我们提供的服务付费的人）和内部客户（紧随我们立即接收和处理工作的人）。根据精益原则，我们最重要的客户是我们的下游。 >> 在技术价值流中，我们通过为运维而设计来为下游工作中心做优化，包括运维的非功能性需求（如架构、性能、稳定性、可测试性、可配置性和安全性）与用户功能同样重要。 ◆ 第4章 第三步：持续学习与实验原则 >> 通过不断向系统加压的方式，来强化持续改进。在可控的情况下，我们甚至通过在生产环境里模拟或者注入故障来增强弹性（resilience）。 >> 如果不指责，员工就没有了恐惧，没有了恐惧，就能够做到坦诚，而坦诚能够有效预防事故。 >> 还可以通过演习的方式来预演大规模故障，比如关闭某个数据中心。或者在生产环境中注入大规模故障（如Netflix著名的“捣乱猴”，它会随机杀死生产环境中的进程和服务器），来验证系统的可靠性是否达到了预期。 ◆ 第5章 选择合适的价值流作为切入点 >> 绿地项目是指在未开发的土地上建设的项目，而棕地项目则是指在以前用于工业生产的土地上建设的项目 >> DevOps绿地项目通常是指一些试点项目，用于证明公有云或私有云方案的可行性，或者尝试采用自动化部署工具或相关工具等。 >> 在双模IT中，传统的记录型系统是指类似于ERP的系统（例如MRP系统、人力资源系统、财务报表系统等），它的交易和数据的正确性是至关重要的；交互型系统则是指面向客户或员工的可交互系统，例如电子商务系统和办公软件。 >> “类型1”，侧重于“做得正确” >> “类型2”，侧重于“做得快速”。交互型系统的变化速度通常较快，因为它需要快速响应反馈，通过实验找到最能满足客户需求的方式。 ◆ 第6章 理解、可视化和运用价值流 >> 在选择好DevOps试点应用或服务后，必须确定价值流的所有成员，他们有责任共同为客户创造价值。一般来说，包括以下这些成员： ❏ 产品负责人：作为业务方的代言人，定义系统需要实现的功能。 ❏ 开发团队：负责开发系统功能。 ❏ QA团队：给开发团队提供反馈，并确保系统功能符合需求。 ❏ 运维团队：负责维护生产环境，并确保系统能够良好地运行。 ❏ 信息安全团队：负责系统和数据的安全。 ❏ 发布经理：负责管理和协调生产环境部署以及发布流程。 ❏ 技术主管或价值流经理：（根据精益方法论的定义）负责“从始至终地保障价值流的产出满足或超出客户（和组织）期望”。 >> 在价值流中，最初的工作是确定客户需求或进行业务构思，这由产品负责人完成 >> 绘制价值流图的目标并不是记录所有的步骤和细节，而是识别出阻碍价值流快速流动的环节，从而缩短前置时间和提高可靠性。 >> 将20%的时间用于创造用户不可见的正面价值 -> 产品负责人需要考虑把团队20%的资源分配给与工程相关的活动，用于重写或重构代码库中有问题的部分，或者工程师认为有必要改进的部分 >> 缓解员工的技术债务压力也可以降低工作倦怠程度。 >> 决定彻底停止新特性的开发工作，把整个部门投入到整顿网站核心基础设施中去，这被称为“反转行动”。 >> 在LinkedIn的系统架构被重构之前，不做任何新特性开发——这是公司和团队需要做的”。 ‘反转行动’使整个开发部门都专注于改进工具、部署流程、基础设施和开发人员的生产力。 >> 通过偿还近10年的技术债务，LinkedIn的“反转行动”实现了稳定性和安全性，同时为公司下一阶段的成长奠定了基础。然而，它花费了两个月处理非功能性需求，并以牺牲在IPO时向市场承诺的特性为代价。 >> 共享队列的另一个好处是统一了任务列表，每个人都能从全局的角度思考优先级最高的事情，选择对组织最有价值的工作，或能最大限度地偿还技术债务的工作。在发现技术债务时，如果不能立即解决，可以将它添加到任务列表中。对于待解决的问题，可以使用为非功能性需求预留的20%的时间进行修复。 >> 为了强化共同目标，也可以使用聊天室，例如IRC频道、HipChat、Campfire、Slack、Flowdock和OpenFire。 ◆ 第7章 参考康威定律设计组织结构 >> 这些不当的方式包括按职能划分团队（例如将开发人员和测试人员安置在不同的办公地点，或者完全外包测试人员），以及按架构层次拆分团队（如应用层、数据库层等）。 不当的组织方式需要各个团队进行大量的沟通和协调，但仍然可能导致大量返工、对需求定义有分歧、工作交接低效，以及由于等待上游人员完工而造成的人员闲置等。 >> 理想情况下，软件的架构应该保证小团队能够独立运作，彼此充分解耦，从而避免过多不必要的沟通和协调。 >> 如果架构能够支持小团队独立、安全、快速地进行开发、测试和部署，就可以提高和维持开发人员的生产力，并改善部署质量。面向服务架构（Service-Oriented Architecture, SOA）就具有这种特征。 ◆ 第8章 将运维融入日常开发工作 >> 每日站会是Scrum所推崇的形式。这是速战速决的会议，团队的所有成员聚到一起，每个人都要向大家讲清楚三点：昨天做了什么？今天要做什么？遇到了什么难题？ ◆ 第9章 为部署流水线奠定基础 >> 我们不再需要运维团队手动构建和配置环境，而是可以使用自动化的方式完成以下操作： ❏ 复制虚拟化环境（如VMware虚拟机镜像、执行Vagrant脚本，以及启动Amazon EC2虚拟机镜像文件）； ❏ 构建“裸金属物理机”的自动化环境搭建流程（例如，使用PXE方式通过基线镜像进行安装）； ❏ 使用“基础设施即代码”的配置管理工具（例如Puppet、Chef、Ansible、SaltStack、CFEngine等）； ❏ 使用操作系统自动化配置工具（例如Solaris Jumpstart、Red Hat Kickstart和Debian preseed）； ❏ 使用一组虚拟镜像或容器（例如Vagrant和Docker）搭建环境； ❏ 在公有云（例如Amazon Web Services、Google App Engine和Microsoft Azure）、私有云或其他PaaS（平台即服务，如OpenShift和Cloud Foundry等）中创建新环境。 >> 为了确保即使在发生灾难性事故时，也可以重复且精确地（最好还能快速地）恢复生产环境，必须把下列资源也纳入版本控制系统： ❏ 应用的所有代码和依赖项（例如库、静态内容等）； ❏ 任何用于创建数据库模式的脚本、应用的参考数据等； ❏ 上一节描述的所有用于搭建环境的工具和工件（例如VMware或AMI虚拟机模板、Puppet或Chef配置模块等）； ❏ 任何构建容器所使用的文件（例如Docker或Rocket的定义文件和compose文件等）； ❏ 所有支持自动化测试和手动测试的脚本； ❏ 任何支持代码打包、部署、数据库迁移和环境置备的脚本； ❏ 所有项目工件（例如需求文档、部署过程、发布说明等）； ❏ 所有云平台配置文件（例如AWS CloudFormation模板、Microsoft Azure Stack DSC文件，以及OpenStack HEAT模板文件）； ❏ 创建支持多种基础设施服务（例如企业服务总线、数据库管理系统、DNS区域文件、防火墙配置规则和其他网络设备）所需的任何其他脚本或配置信息。 >> 通过重复创建环境，我们能够将更多的服务器添加到资源池，从而轻松地增加容量（即水平扩容）。 >> 为了确保环境的一致性，所有对生产环境的变更（配置变更、打补丁、升级等）都需要被复制到所有的预生产环境以及新搭建的环境中。 >> 可以依靠自动化配置管理系统保证一致性（例如Puppet、Chef、Ansible、Salt、Bosh等） >> 在Scrum方法论中，冲刺（sprint）是一个用时固定的开发周期（通常一个月或更短）。在这个时间段内，需要将任务完成，即要产出“可工作和可交付的代码”。 ◆ 第10章 实现快速可靠的自动化测试 >> “理想的测试金字塔”这一概念，即使用单元测试捕获大部分错误 ◆ 第12章 自动化和低风险发布 >> 大多数具有持续集成和测试功能的工具，也有扩展部署流水线的能力。通常在生产验收测试执行完之后，这些工具可以将验证过的构建版本发布到生产环境中（这样的工具包括Jenkins Build Pipeline插件、ThoughtWorks的GoCD和Snap CI、Microsoft Visual Studio Team Services，以及Pivotal Concourse）。 >> 部署过程中，应该测试依赖的所有系统（例如数据库、消息总线和外部服务）是否能正常访问，并通过单次测试看看系统是否能正常工作。如果以上任何一个测试失败，那么部署就是失败的。 >> 为了更好地促进工作，需要一个可以由开发人员或运维人员来执行的代码发布流程，并且在理想情况下，应该不需要任何手动操作或工作交接。这个流程的步骤如下。 ❏ 构建：部署流水线必须基于版本控制系统构建可部署到任何环境（包括生产环境）的软件包。 ❏ 测试：任何人都应该能够在他们的工作站上或测试系统中运行任何一个自动化测试套件。 ❏ 部署：任何人都应该能够将这些软件包部署到具有访问权限的任何环境，通过执行（已提交到版本控制系统中的）脚本来完成部署。 >> 部署是指在特定的环境中安装指定版本的软件（例如，将代码部署到集成测试环境中或生产环境中）。具体地说，部署可能与某个特性的发布相关，也可能无关。 >> 发布是指把一个特性（或者一组特性）提供给所有客户或者一部分客户（例如，向5%的客户群开放特性）。 >> 基于环境的发布模式：在两个或更多的环境中部署系统，但实际上只有一个环境处理客户流量（例如，通过配置负载均衡器切换流量） >> 这种模式包括蓝绿部署、金丝雀发布和集群免疫系统。 >> 基于应用的发布模式：对应用进行修改，从而通过细微的配置变更，选择性地发布或开放应用特性。例如，可以通过特性开关逐渐地开放新特性——先开放给开发团队，再开放给所有内部员工，然后开放给1%的客户；或者在确认特性完全符合设计后，直接发布给全体客户。这就是所谓的黑启动技术——在生产环境里将所有特性都部署完毕，并在发布前用生产环境的流量做测试。 >> 蓝绿部署是3种模式中最简单的一种。在这种模式下，我们有两个生产环境：蓝环境和绿环境。在任一时刻，只有其中的一个环境处理客户流量。 >> 金丝雀发布这个术语来自于煤矿工人把笼养的金丝雀带入矿井的传统。矿工通过金丝雀来了解矿井中一氧化碳的浓度。如果一氧化碳的浓度过高，金丝雀就会中毒，从而使矿工知道应该立刻撤离。 >> ❏ A1组：仅向内部员工提供服务的生产环境服务器。 ❏ A2组：仅向一小部分客户提供服务的生产环境服务器，在软件达到某些验收标准后部署（自动化部署或手动部署均可）。 ❏ A3组：其余的生产环境服务器，软件在A2组中达到某些验收标准后再部署。 >> 基于应用的发布模式主要是通过特性开关来实现的。 >> 特性开关还具有如下优势。 ❏ 轻松地回滚： ❏ 缓解性能压力： 可以使用特性开关来缓解系统的性能压力。换句话说，可以通过减少可用的特性，来支持更多的用户（例如，减少使用某特性的客户数量，禁用推荐等CPU密集型特性，等等）。 ❏ 采用面向服务架构提高恢复能力：即便某个特性依赖于还没有上线的服务，仍然可以将这个特性部署到生产环境中，然后用特性开关把它先隐藏起来。当它所依赖的服务上线后，就可以启用这个特性。同样，当所依赖的服务中断时，也可以关闭该特性，这样做不但可以和下游的故障服务隔离，同时还可以保持应用的其余部分正常运行。 >> 为了保证能发现所有特性的缺陷，应该在打开所有特性开关的情况下执行自动化验收测试。（还应该测试特性开关功能本身是否正常！） >> 特性开关实现的效果是，将特性部署到生产环境中，但暂时使其不可用 >> 我们可以让1%的在线用户对将要发布的新特性做隐式调用，同时观察新特性在此工作负载下的表现。在发现并解决完所有问题后，提高用户访问频率并增加用户数量，以此逐渐增加模拟的负载。 >> 这种方式使得每个Facebook用户都成为大规模负载测试的一份子 >> 持续交付是指，所有开发人员都在主干上进行小批量工作，或者在短时间存在的特性分支上工作，并且定期向主干合并，同时始终让主干保持可发布状态，并能做到在正常的工作时段里按需进行一键式发布。 >> 持续部署是指，在持续交付的基础上，由开发人员或运维人员自助式地定期向生产环境部署优质的构建版本， >> 持续交付是持续部署的前提条件，就像持续集成是持续交付的前提条件一样。 ◆ 第13章 降低发布风险的架构 >> 绞杀者应用（strangler application）模式，而不是在无法继续满足组织目标的架构上直接“剥离和替换”旧服务。 >> 2004年，Martin Fowler创造了绞杀者应用这一术语。这源于他在澳大利亚旅行时由当地藤类绞杀植物得到的启发。他写道：“它们的种子落在无花果树的顶部，然后藤蔓逐渐沿树干向下生长，最后在土壤中生根。多年以后，藤蔓形成奇妙和美丽的形状，但同时绞杀了其宿主树。” >> 如果确信已有的架构过于紧耦合，那么可以在其基础上安全地解耦部分功能。通过这种方式，负责这些功能的开发团队能够独立且安全地进行开发、测试和部署，同时减少了架构的熵。 ◆ 第14章 建立能发现并解决问题的遥测系统 >> 遥测被广泛定义为“一个自动化的通信过程，先在远程采集点上收集度量数据，然后传输给与之对应的接收端用于监控”。 >> LAMP栈（Linux、Apache、MySQL和PHP） >> 平均修复时间（MTTR） >> 前端通常会使用图形用户界面展示，而后端经常使用诸如Crystal Reports等工具来补充。 >> 操作系统级别，可以使用collectd、Ganglia等工具采集状态指标，如CPU、内存、磁盘或网络的使用率等。使用其他工具来采集性能指标，这些工具包括AppDynamics、New Relic和Pingdom等。 >> 日志还要具有不同的级别，其中的一些可能也会触发告警， >> ❏ 调试级别：此级别的信息是相关应用程序中发生的所有事件，最常用于调试的时候。通常，调试日志在生产中是禁用的，但在故障诊断期间要暂时启用。 ❏ 信息级别：此级别的信息包括用户触发的或系统特定的操作（例如“开始信用卡交易”）。 ❏ 警告级别：此级别的信息告诉我们可能的出错情况（例如，调用数据库花费的时间超过某个特定时长）。可能会因此而触发报警和故障诊断过程，而其他日志消息会有助于更好地理解事件的原因。 ❏ 错误级别：此级别的信息侧重于错误状况（例如，API调用失败，内部出错）。 ❏ 致命级别：此级别的信息告诉我们何时发生了中断情况（例如，网络守护进程无法绑定网络套接字）。 >> 为了帮助确保拥有与服务可靠性和安全操作相关的信息，我们应该保证所有潜在的重大应用事件都生成日志记录条目，包括高德纳公司GTP安全和风险管理小组的研究副总裁Anton A. Chuvakin编写的以下清单： ❏ 认证/授权的结果（包括退出）； ❏ 系统和数据的访问； ❏ 系统和应用程序的变更（特别是特权变更）； ❏ 数据的变更，例如增加、修改或删除数据； ❏ 无效输入（可能的恶意注入、威胁等）； ❏ 资源（内存、磁盘、中央处理器、带宽或其他任何具有硬/软限制的资源）； ❏ 健康度和可用性； ❏ 启动和关闭； ❏ 故障和错误； ❏ 断路器跳闸； ❏ 延迟； ❏ 备份成功/失败。 为了更容易地解释和给出所有日志条目的意义，（理想情况下）我们应该对日志记录进行分级和分类，比如对非功能属性（如性能、安全性）和功能属性（如搜索、排行）。 >> 大部分生产环境问题都是由变更引起的，包括代码部署。 >> 我们需要在所有环境中，在应用程序栈的每个层级中，以及支持它们的部署流水线中，建立充分而完整的遥测。我们需要以下层级的度量指标。 ❏ 业务级别：示例包括交易订单的数量、产生的营业额、用户注册数、流失率、A/B测试的结果等。 ❏ 应用程序级别：示例包括事务处理时间、用户响应时间、应用程序故障等。 ❏ 基础架构级别（如数据库、操作系统、网络、存储）：示例包括Web服务器吞吐量、CPU负载、磁盘使用率等。 ❏ 客户端软件级别（如客户端浏览器上的JavaScript、移动应用程序）：示例包括应用程序的出错和崩溃、用户端的事务处理时间等。 ❏ 部署流水线级别：示例包括构建流水线状态（例如：各种自动化测试套件的红色或绿色状态）、变更部署前置时间、部署频率、测试环境上线状态和环境状态。 >> 现在，这些连接越来越多地在服务中自动注册。随后，在生产环境中，通过Zookeeper、Etcd、Consul等工具，可以动态地发现和使用这些服务。 ◆ 第16章 应用反馈实现安全部署 >> 我们的目标是在软件进入生产环境之前，在部署流水线中就发现错误。然而，还是存在着检测不到的错误，这就要依靠生产环境的遥测来快速恢复服务了。我们可以使用特性开关关闭出错的功能（这通常是最简单且风险最小的选择，因为它不涉及生产部署），或者前向修复这个错误（即为了修复缺陷而修改代码，然后通过部署流水线将代码变更部署到生产环境），或者回退（例如，使用特性开关切换回之前的旧版本，或通过蓝绿部署、金丝雀发布等模式，将出错的服务器做离线处理）。 >> 客户观察是一种非常好的学习形式，并且会激发开发人员去改善客户体验。 ◆ 第17章 将假设驱动的开发和A/B测试融入日常工作 >> 在现代用户体验实践中，最常用的A/B测试技术是，在一个网站上，给访问者随机地展示一个页面的两个版本之一，即控制组（A）或实验组（B）。基于对这两组用户后续行为的统计分析，可以判断这两者的结果是否存在显著差异，从而找出实验组（例如，功能的变化、设计元素、背景颜色）和结果（例如，转化率、平均订单大小）之间的因果联系。 >> 例如，我们可以通过一项实验，看看改变“购买”按钮上的文字或颜色是否会增加收入，或者减慢网站的响应速度（故意给实验组制造延迟）是否会造成收入降低。这种类型的A/B测试让我们在性能优化方面建立了金钱价值观。 有时，A/B测试也称为在线控制实验和拆分测试。在实验的过程中还支持多个变量，从而观察变量之间的相互作用，这种技术称为多变量测试。 >> 通过在生产环境中快速轻松地按需部署，利用特性开关将软件的多个版本同时交付给多个用户群，可以进行快速、迭代的A/B测试。要实现这一点，需要在应用程序栈的各个层次上进行全面的生产环境遥测。 通过勾选特性开关中的选项，可以控制能看到实验组版本的用户比例。例如，可以让一半的客户成为实验组，向其显示“与购物车中失效商品相似商品的链接”。在实验中，我们对比控制组（无选择）和实验组（有选择）的用户行为，可能是衡量在此期间的购买数。 ◆ 第18章 建立评审和协作流程以提升当前工作的质量 >> Pull Request是这样一种机制：让工程师告诉其他所有人，他向GitHub上的仓库推送了一些代码变更。一旦提交了Pull Request，相关人员就能评审所有的代码变更，讨论可能的修改， >> 术语结对和结对编程的含义是相同的，以表明这种实践不只适用于开发人员。 在常见的结对模式中，一名工程师扮演驾驶者角色，他是实际上编写代码的人，而另一名工程师则作为导航员、观察者或督导者，他会检查驾驶者正在进行的工作。 >> 另一种结对编程的模式是通过测试驱动开发进行的，这是指一名工程师编写自动化测试，另外一名工程师编写代码。 ◆ 第19章 将学习融入日常工作 >> 即使AWS的整个可用区域都发生了故障，就像这次美国东部区的事故，也要确保Netflix的服务能够持续运行。要达到这一点就需要系统架构是松耦合的，每个组件都有特别敏感的超时设计，从而保证出现故障的组件不会拖垮整个系统。作为替代，Netflix每个功能和组件都设计为具有完全降级的能力。例如，当流量剧增造成了CPU使用率暴涨的时候，就不向用户显示个性化的电影推荐列表，而是只显示已经缓存的静态内容，从而减少计算资源的需求。 >> 除了实施这些架构模式，他们还构建并运行了一个令人吃惊的大胆服务，称为“捣乱猴”（Chaos Monkey）。它会不断地随机删除生产服务器，来模拟AWS环境故障。他们这样做是希望所有的“工程团队习惯于在常规的故障水平上工作”，使得服务能够“在没有任何人工干预的情况下，自动恢复正常”。 ◆ 第20章 将局部经验转化为全局改进 >> 测试驱动开发（TDD）实践 ◆ 第21章 预留组织学习和改进的时间 >> 有一种称作改善闪电战（improvement blitz或kaizen blitz）的实践，是丰田生产系统的重要组成部分，指的是在一个专门集中的时间段里解决特定问题，通常长达几天。Steven Spear博士解释：“改善闪电战经常采取的形式是，一个小组聚在一起，专注探究一个存在问题的流程……改善闪电战通常持续几天，目标是优化流程，方法则是集中地让流程之外的人给通常在流程里的人提建议。” >> 特别让人感兴趣的就是HipHop PHP编译器。2008年，Facebook面临严重的容量问题——活跃用户超过1亿，而且仍在迅猛增长。这给整个工程团队带来了巨大的麻烦。在一次黑客日里，Facebook高级服务器工程师赵海平开始尝试将PHP代码转换为可编译的C++代码，希望能够大幅度提升现有基础架构的容量。在接下来的两年中，一个小团队集结并构建了这个称为HipHop编译器，将Facebook的所有生产服务从解释型的PHP程序文件转换为了编译型的C++二进制文件。HipHop使Facebook的平台能够处理比原生PHP程序高6倍的生产负载。 ◆ 第22章 将信息安全融入每个人的日常工作 >> 通常，开发阶段的测试关注功能的正确性，着眼点是正确的逻辑流程。这种类型的测试通常称为愉快路径（happy path），它验证的是用户的正常操作流程（有时候存在几个可选的路径）——一切都按预期执行，没有例外或出错状况。 另一方面，QA人员、信息安全人员和欺诈者其实经常关注不愉快路径（sad path），它在事情出错时发生，尤其与安全相关的错误状况有关。（这类安全特定状况常被戏称为坏路径。） >> 有问题的用户行为可以揭示或引发欺诈和未授权的访问，为了进行检测，必须在应用程序中创建相关的遥测系统。 这样的例子包括： ❏ 成功和不成功的用户登录； ❏ 用户密码重置； ❏ 用户电子邮件地址重置； ❏ 用户信用卡更改。 >> 除了完善应用程序，还需要在环境中创建全面的遥测系统，以便能够尽早检测未授权访问的迹象，特别是对于运行在非受控基础设施上（例如，托管环境、云端）的组件。 我们需要对某些事件做监控和告警，包括： ❏ 操作系统的变更（例如，生产环境中、构建基础设施中）； ❏ 安全组的变更； ❏ 配置的变更（例如，OSSEC、Puppet、Chef、Tripwire）； ❏ 云基础设施变更（例如，VPC、安全组、用户和权限）； ❏ XSS尝试（即“跨站点脚本攻击”）； ❏ SQLi尝试（即“SQL注入攻击”）； ❏ Web服务器错误（例如，4××和5××错误）。 ◆ 第23章 保护部署流水线 >> 破坏性测试。这是制造业的术语，指的是在最严酷的操作条件下执行长时间的耐久性测试，直到摧毁测试部件
