DevOps Handbook企业级实施指南(1)--续

CH12 低风险自动化发布

kent beck XP方法的创始人，facebook的技术教练，提到“貌似facebook每次发布处理的变更数是固定的，如果想要更多变更，得多发布”。之前的发布是人工的，耗时的，高风险的，因此尽可能减少发布，这导致每次发布的变更很多，出问题的风险更大，于是形成向下循环。

自动化部署过程

在自动化前，我们就有发布过程文档，我们需要将发布过程尽可能多地自动化。可自动化的内容包括：

用便于部署的方式打包代码

创建预先配置好的虚拟机镜像或容器

自动化部署和配置中间件

将包和文件拷贝到生产服务器

重启服务器、应用、服务

从模板中创建配置文件

运行自动化冒烟测试，确认系统在工作且配置正确

运行测试过程

脚本化和自动化数据库迁移

如可能，我们要重构以去掉一些步骤，尤其是耗时很长的操作。我也也希望不仅仅减少lead time，也包括减少交接此事，以减少错误和知识的损失。

对部署流水线的需求包括：

所有环境都用同样的方式部署:通过在所有环境使用同样的部署机制，在生产的部署成功率大大提高。因为同样的操作在流水线上已经成功执行很多次。

对部署进行冒烟测试:在部署过程中，我们应该测试是否能够连接到支持系统（如数据库、总线、外部服务），并运行一个交易确保系统能正常运行。如果前述测试失败，部署就失败。

维护一致的环境:通过一键创建环境，开发、测试、生产环境有了一致的创建过程，以后得时刻保持环境的同步。

将自服务部署自动化

因为需要控制和监管，以及安全和合规(compliance)需求，开发人员已经很久没有自己发布将代码部署到生产，快速看到因能用新特性而开心的客户，能够快速修复任何问题而不需要运维先进行登记。

通常的做法是运维来部署代码，这既是因为分工的概念深入人心，也是为了减少事故和欺诈（怕监守自盗？）。然后为了获得devops的效率，我们需要采用其他控制机制来获得同样甚至更好的缓解上述风险的效果，包括自动化测试、自动化部署、对变更进行同行评审等。

2013的devops报告发现，由开发部署代码比由运维部署代码的成功率在统计上有显著的差别。

换句话说，随着开发和运维对部署共担责任，以及透明，职责和责任，谁来执行发布没什么关系。事实上，我们可以让其他角色，比如测试和项目经理来在相关环境进行部署，以便他们能快速完成他们的工作，比如部署UAT环境用于演示等。

为了获得更快的流(flow)，我们需要一个任何人都能执行的代码晋级过程(code promotion process)，最好是没有人工操作和交接的。这样会影响一下步骤：

构建:我们部署流水线能够从版本库生成用于部署到任何环境甚至生产环境的包。

测试:任何人都能在自己的工作站或测试环境中运行任何或所有自动化测试。

部署:通过执行也放在版本库中的脚本，任何人都能在他们访问到的任何环境中部署这些包

这样，不管谁来执行部署，都能成功。

将代码部署集成到部署流水线中

部署自动化后，这部分工作也能合并到部署流水中，这样，我们的部署自动化就能带来以下效果：

确保持续集成过程产生的包能被部署到生产

show the readiness of production env at a glance

提供一键自助将选择包部署到生产环境的方法

为审计和合规自动记录，包括在哪台机器执行的命令，谁授权的，结果是什么

通过执行冒烟测试，确保能正常操作，配置数据库连接串是正确的

给部署的人快速反馈，以便他们马上看到部署是不是成功的

我们不想不得不等待数小时才知道部署是成功还是失败，然后再等数小时发布修复代码。现在有了容器等技术，复杂的部署也能在分钟和秒级完成。

通过这些实践，我们有了一个“部署”按钮，依托部署流水线，我们可以快速安全地将代码变更发布到生产。

案例研究

略(后面再看)

将部署和发布解耦(decouple deployment from release)

软件项目发布版本的传统的做法是根据市场确定的日期，提前一天晚上部署到生产系统中，次日开放。然后宣布新的能力开放，开始接受订单，给客户交付新的功能等。

然后计划总是跟不上变化。我们可能会遇到超出我们测试或设计的负载，导致服务大量失败。更糟糕的是，因为要对生产系统做变更，回滚和修复(fix forward)的风险一样大。等到所有问题解决，大家松了口气，祈祷着千万不要经常部署和发布。

当然，我们知道为了获得平滑和快速的流，我们需要频繁发布。当我们能够按需发布，那么将新特性开放给客户就成了市场决策，而不是技术决策。我们有两类发布模式：

基于环境的发布模式:我们有两至多套环境，但只有一套环境接受客户流量（比如通过负载均衡）。新的代码部署到non-live 环境，然后通过流量迁移逐渐发布。蓝绿部署、金丝雀发布、cluster immune system都属于这一类。

基于应用的发布模式:通过修改应用，使得应用支持修改配置来选择性发布和开放功能。比如采用feature flag，在生产环境渐进地将功能开发给开发团队、内部雇员和部分客户，直到有信心开发给所有客户。这样我们就实现了dark launching。

==即在生产发布不实部署代码，而是切换流量或打开开关==

基于环境的发布模式

蓝绿部署模式

处理数据库变更

案例研究

略

金丝雀和cluster immune system发布模式

基于应用的发布模式更安全

实现feature flag

实施dark launchies

案例研究

略

持续交付和持续部署调研

本章小结

CH13 为低风险发布设计架构

第四部分反馈的技术实践

第三部分是创建从开发到运维快速流的实践，第四部分是描述怎样实现从运营到开发的持续和快速反馈的实践。以此缩短和放大反馈环，当问题发生时就会被看到并将信息发射(radiate)给价值流中的所有人。更进一步，我们要创建一个工作系统，将下游运维需要的知识集成到上游开发和产品管理中，我们将迅速获得提升和学习，不管这来自生产问题、部署问题，还是早期苗头和客户使用模式。

此外，我们将创建一个过程，让每个人在工作中学习，在信息可见并触动学习，推动快速测试产品假设和，帮助我们判断新的特性是不是有助于我们达成组织目标。

CH14 通过遥测技术看到和解决问题

运营中面临的情况是事情总是会出错--小的变更导致很多预料之外的结果，包括故障和影响客户的全面失败。这就是复杂系统的特点，没有一个人能看清系统整体并理解每一块合在一起时候的表现。

日常工作中我们常遇到一个情况，即故障发生时，没有得到需要解决问题的信息。比如不知道故障是因为代码缺陷，还是环境问题，或者是外部服务导致。

遥测(telemetry)，宽泛的定义是“通过在远端度量和收集数据并传输到监控接收设备实现一种自动化的沟通过程”

2015年的devops报告中，最利于MTTR指标的两项实践分别是运营使用版本控制和对生产进行遥测和主动监控。

创建中心化的遥测基础架构

对生产环境监控不是什么新玩意，将日志和遥测数据分析结果用于应用开发也不是新鲜事。但两者经常是割裂的，开发记录开发人员关心的日志，而运维只监控环境是启动的还是挂掉了。这样当事情发生时，就很难明白到底为啥系统整体运行不符合设计，和不知道具体哪个组件出问题了。

为了在所有问题在出现时就被看到，我们得设计应用和环境以产生足够的遥测（能力），这样我们能看到系统作为一个整体的行为是怎样的。随着应用栈所有层次的监控和日志，我们其他方面的能力也会挖掘出来，比如图形化和可视化度量数据，异常检测，主动告警和弹性扩展。

在“The Art of Mornitoring”(==有这本书吗？得找找==)中定义了现代监控体系结构，这个结构有以下组件：

在业务逻辑、应用和环境层收集数据:在每一层，我们基于事件、日志和度量创建遥测。

用于存储和度量事件的方法(router):这样我们就具备可视化、分析趋势、告警、异常检测等能力。通过收集、存储和聚合所有“遥测”，我们能更好地进行深入分析和健康检查。这通常也是我们存储服务配置的地方，也是进行基于阈值的告警和健康检查的地方。

通过集中化的日志，我们可以在整个系统对事件级（同类事件，比如core)进行求和以形成度量；通过将日志转化成度量，我们可以进行统计分析，比如异常检测，这样可以发现早期问题。

除了对生产服务和环境进行遥测，我们还得对部署流水线的重要事件进行遥测，比如在任何环境部署后的自动化测试成功和失败。还要收集构建和测试执行的时间等，这样我们可以检测潜在的问题，比如性能测试或构建比往常慢了一倍。

image.png

更进一步，我们需要容易地从遥测结构中获取信息，最好是自服务的API，而不是要提个单子然后等待报告。

理想情况下，我们的遥测能报告所有感兴趣的事发生时的准确情况，以及发生在哪里和怎样发生的。要能够在没有应用的情况下做人工和自动的分析。某种程度上说，监控系统要比被监控的系统要求更高，要有更好的可用性和可扩展性。

下文遥测和度量是一个意思，包括生产环境、预生产环境、部署流水线所有应用栈所有层次产生的事件日志和度量数据。

创建帮助生产的应用日志遥测

有了集中化的遥测基础设施，我们得确保应用产生足够的遥测。我们通过让开发测试未新增和存量服务创建生产遥测作为日常工作来达到这个目的。

如同NASA发生火箭需要有数以百万计的传感器每时每刻报告状态一样，我们为软件创建的遥测也是我们所做最有价值的事（投资回报最高的事情）。

应用中每个特性都必须仪表化--如果足够重要的话，事实上如果不重要，就不会去实现。

价值流中的不同成员会用不同的方式使用遥测。比如开发需要用于分析开发环境BUG的遥测，而运维需要诊断生产问题，信息安全和审计要review必须的控制，产品经理要跟踪业务产出，特性使用或转化率。

为了支持不同的使用模型，需要对日志分级记录：

DEBUG Level:

INFO Level:

WARN Level:

ERROR Level:

FETAL Level:

选择日志级别很重要。ThoutWorks的顾问发现，“当确定要用ERROR还是WARN时，就看是不是会被凌晨4点被叫起来，低于这个就不是ERROR”。(==可能组织级要规范下定义==)

为了确保我们有足够的有关可靠性和安全的信息，重要的应用事件必须有记录下来：

认证/授权决策(包括下线)

系统和数据访问

系统和应用变更(尤其是权限)

数据变更，例如增加、编辑或删除数据

非法输入(可能的恶意注入和威胁)

资源(RAM、磁盘、CPU、带宽，及其他有或硬或软限制的资源)

健康和可用性

启动和停止

故障和错误(faults or errors)

断路器跳闸(circuit breaker trips,是不是指流控、服务降级等？)

延迟

备份成功和失败

为了让日志项好理解和有意义，我们需要创建日志分级分类，比如非功能属性(性能、安全等)和功能属性(搜索、排列等)

用遥测指导解决问题

本章开头有讲高绩效的人用严格的方法解决问题。与此相反的更寻常的实践是利用谣言和道听途说，这导致可悲的度量“自证清白平均时间”。

这一般发生在会因故障和问题被指责的文化中，为了避免被指责/定责，就不会不充分充分展示遥测，于是问题解决很困难。

科学的方法会用遥测确定导致问题和哪些问题需要解决的假设。解决问题时我们可以问的问题包括：

从监控中我们能够得到什么证据说明问题真的发生了？

有哪些应用和环境的变更和这个问题相关？

我们能形成什么假设来建立因果关系？

我们怎样才能证明哪个假设是正确的，可用于解决问题？

基于事实的问题解决不仅和MTTR密切相关，而且有利于在开发、运维之间建立双赢观念。

==注：本节描述的问题我们不应该出现，我们的开发和运维之间的沟通是基于事实和坦诚的==

将创建生产遥测作为日常工作

创建遥测和信息发射器的自服务访问方法

发现和填满任何遥测空白(fill gaps)

应用和业务度量

基础设施度量

将其他有关信息填补到我们的度量中

本章小结

CH15 分析遥测数据分析问题，达到目标

CH16 通过快速反馈让开发和运维安全地发布代码

CH17 在日常工作中集成假设驱动和AB测试

CH18 通过审视与写作流程提高当前工作质量

第五部分 持续学习和体验的技术实践

CH19 让学习成为每天的工作

CH20 将局部发现转化成全局提升

CH21 为组织学习(organiztion learning)和提升预留时间

第六部分 集成信息安全、变更管理、合规的技术实践

CH22 信息安全是每个人日常工作

CH23 保护部署流水线

來源：简书

著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。