架构师训练营第 11 周学习总结

11.1 安全架构：Web 攻击与防护

• XSS 攻击

• XSS 攻击防御手段

• 消毒：XSS 攻击者一般都是通过在请求中嵌入恶意脚本达到攻击目的，这些脚本是一般用户输入中不使用的，如果进行过滤和消毒处理，即对某些 HTML 危险字符转义，如“>”转义为“&gt”、“<”转义为“&lt”等，就可以防止大部分攻击。为了避免对不必要的内容错误转义，如“3<5”中的“<”,需要进行文本匹配后再转义，如“<img src=”这样的上下文中“<”才转义。事实上，消毒几乎是所有网站最必备的 XSS 防攻击手段。

• SQL 注入攻击

• 获取数据库表结构信息的手段

• 开源：如果网站采用开源软件搭建，如用 Discuz! 搭建论坛网站，那么网站数据库结构就是公开的，攻击者可以直接获得。

• 错误回显：如果网站开启错误回显，攻击者故意构造非法参数，服务端异常信息会输出到浏览器端，为攻击猜测数据库表结构提供了便利。

• 盲注：网站关闭错误回显，攻击者根据页面变化情况判断 SQL 语句的执行情况，据此猜测数据库表结构，此种方式攻击难度较大。

• 注入攻击防御手段

• 消毒：和防 XSS 攻击一样，请求参数消毒是一种比较简单粗暴又有效的手段。通过正则匹配，过滤请求数据中可能注入的 SQL 文。

• 如“drop table”、“\b(?:update\b.*?\bset|delete\b\W*?\bfrom)\b”等。

• SQL 预编译参数绑定：使用预编译手段，绑定参数是最好的防 SQL 注入方法。目前许多数据访问层框架，如 myBatis，Hibernate 等，都实现 SQL 预编译和参数绑定，攻击者的恶意 SQL 会被当做 SQL 的参数，而不是 SQL 命令被执行。

• CSRF 攻击

• CSRF 攻击防御手段

• 表单 Token：CSRF 是一个伪造用户请求的操作，所以需要构造用户请求的所有参数才可以。表单 Token 就是阻止攻击者获得所有请求参数的可能，在页面表单中增加一个随机数 Token，每次请求的 Token 都不相同，请求提交后检查 Token 的值是否正确以确定请求提交者是否合法。

• 验证码：相对说来，验证码则更加简单有效，即请求提交时，需要用户输入验证码，以避免在用户不知情的情况下被攻击者伪造请求。但是输入验证码是一个糟糕的用户体验，所以必要的时候才使用，如支付交易等关键页面。

• Referer check：HTTP 请求头的 referer 域中记录着请求来源，可通过检查请求来源，验证其是否合法。但是该方法有一定局限性，referer 也并不一定总能得到。

• 其他需要关注的攻击和漏洞

• Error Code：也称作错误回显，许多 Web 服务器默认是打开异常信息输出的，即服务器端未处理的异常堆栈信息会直接输出到客户端浏览器，这种方式虽然对程序调试和错误报告有好处，但同时也给黑客造成可乘之机。通过故意制造非法输入，使系统运行时出错，获得异常信息，从而寻找系统漏洞进行攻击。防御手段也很简单，通过配置 Web 服务器参数，跳转 500 页面（HTTP 响应码 500 表示服务器内部错误）到专门的错误页面即可，这个功能 Web 应用常用的 MVC 框架也可以做到。

• HTML 注释：为了程序调试方便或其他不恰当的原因，有的时候程序开发人员会在 PHP、JSP 等服务器页面程序中使用 HTML 注释语法进行程序注释，这些 HTML 注释就会显示在客户端浏览器，给黑客造成攻击便利。程序最终发布前需要进行代码 review 或自动扫描，避免 HTML 注释漏洞。

• 文件上传：一般网站都会有文件上传功能，设置头像、分享视频、上传附件等。如果上传的是可执行的程序，并通过该程序获得服务器端命令执行能力，那么攻击者几乎可以在服务器上为所欲为，并以此为跳板攻击集群环境的其他机器。最有效的防御手段是设置上传文件白名单，只允许上传可靠的文件类型。此外还可以修改文件名、使用专门的存储等手段，保护服务器免受上传文件攻击。

• 路径遍历：攻击者在请求的 URL 中使用相对路径，遍历系统未开放的目录和文件。防御方法主要是将 JavaScript、CSS 等资源文件独立服务器、独立域名，其他文件不使用静态 URL 访问，动态参数不包含文件路径信息。

• Web 应用防火墙

• 开源 Web 应用防火墙 ModSecurity

• ModSecurity 是一个开源的 Web 应用防火墙，探测攻击并保护 Web 应用程序，既可以嵌入到 Web 应用服务器中，也可以作为一个独立的应用程序启动。ModSecurity 最早只是 Apache 的一个模块，现在已经有 Java、.NET 多个版本，并支持 Nginx。

• ModSecurity 采用处理逻辑与规则集合分离的架构模式。处理逻辑负责请求和响应的拦截过滤，规则加载执行等功能。而规则集合则负责对具体的攻击的规则定义、模式识别、防御策略等功能。处理逻辑比较稳定，规则集合需要不断针对漏洞进行升级，这是一种可扩展的架构设计。

• 网站安全漏洞扫描

• 和电脑安全漏洞扫描一样，网站也需要安全漏洞扫描。

• 网站安全漏洞扫描工具是根据内置规则，模拟黑客攻击行为，用以发现网站安全漏洞的工具。许多大型网站的安全团队都有自己开发的漏洞扫描工具，不定期的对网站的服务器进行扫描，查漏补缺。

• 目前市场上也有很多商用的网站安全漏洞扫描平台。

11.2 安全架构：加密与解密

• 信息加密技术及密钥安全管理

通常，为了保护网站的敏感数据，应用需要对这些信息进行加密处理，信息加密技术可分为三类：单项散列加密，对称加密，非对称加密。

• 单向散列加密

• 加密的过程是单向的，用户从明文加密成密文以后，是不能够通过密文再反算或解密出来明文。

• 典型的是对用户的密码加密。加“盐”(Salt)

• 对称加密

• 加密算法对称解密算法，使用相同的密钥，可以把密文重新反算出明文。

• 非对称加密

• 明文通过加密算法和密钥算出来密文，密文通过解密算法算出来明文，非对称加密解密的密钥和加密的密钥是不一样的。

• HTTPS

• 比特币区块链

• 密钥安全管理与加解密服务系统架构

11.3 安全架构：反垃圾与风控

• 反垃圾邮件

• 贝叶斯分类算法

• 利用贝叶斯算法进行垃圾邮件的识别，根据已分类的样本信息获得一组特征值的概率（如“茶叶”这个词出现在垃圾邮件中的概率和非垃圾邮件中的概率），就得到分类模型，然后对待处理信息提取特征值，结合分类模型，判断其分类。

• 贝叶斯公式

• 布隆过滤器黑名单

• 把垃圾邮箱地址(字符串)，通过 8 个函数计算出 8 个值。8 个值把 8 个位置标为 1。下一次来检查邮箱是否是黑名单邮箱时，还是计算 8 个数值，然后检查数值对应的二进制位，如果 8 个数值都是 1，就是在黑名单中，只要有一个地址不是 1，就不在黑名单中。

• 用较小的空间存储大量的地址。

• 有错判，没有漏判

• 电子商务风险控制

• 电子商务具有多种形式，B2B，B2C，C2C 每种交易的场景都不相同，风险也各有特点，大致可分为以下几种：

• 账户风险：包括账户被黑客盗用，恶意注册账号等几种情形。

• 买家风险：买家恶意下单占用库存进行不正当竞争；黄牛利用促销抢购低价商品；此外还有良品拒收，欺诈退款以及常见于 B2B 交易的虚假询盘等。

• 卖家风险：不良卖家进行恶意欺诈的行为，例如货不对板，虚假发货，炒作信用等，此外还有发布违禁商品、侵权产品等。

• 交易风险：信用卡盗刷，支付欺诈，洗钱套现等。

• 规则引擎

• 机器学习

11.4 高可用：可用性度量

• 可用性指标

• 网站年度可用性指标＝（1－网站不可用时间/年度总时间）×１００％

• 网站不可用时间（故障时间）＝故障修复时间点－故障发现（报告）时间点

• 对可用性的定性描述，两个 9 是基本可用，年度停机时间小于 88 小时；3 个 9 较高可用，年度停机时间小于 9 小时；4 个 9 是具有自动恢复能力的高可用，年度停机时间小于 53 分钟；5 个 9 是极高可用性，年度停机时间小于 5 分钟。由于可用性影响因素很多，对于网站整体而言，达到 4 个 9，乃至 5 个 9 的可用性，除了过硬的技术、大量的设备资金投入和工程师的责任心，还要有个好运气。

• 故障分管理

• 故障处理流程及考核

• 引起故障的原因

• 硬件故障 - 交换机

• 软件 bug -

• 系统发布 - 数据库没增加字段

• 并发压力

• 网络攻击

• 外部灾害 - 挖断光纤

11.5 高可用：提升系统可用性的架构方案

• 解耦 - 代码的低耦合有利于提升系统的可用性

• 高内聚、低耦合的组件设计原则

• 面向对象基本设计原则

• 面向对象设计模式

• 领域驱动设计建模

• 隔离

• 业务与子系统隔离

• 微服务与中台架构

• 生产者消费者隔离 - 消息队列

• 虚拟机与容器隔离

• 异步

• 多线程编程

• 反应式编程

• 异步通信网络编程

• 事件驱动异步架构

• 备份

• 集群设计

• 数据库复制

• CAP 原理

• Failover（失效转移）

• 数据库主主失效转移

• 负载均衡失效转移

• 如何确认失效，需要转移？

• 设计无状态的服务

• 幂等

• 应用调用服务失败后，会将调用请求重新发送到其他服务器，但是这个失败可能是虚假的失败。比如服务已经处理成功，但是因为网络故障应用没有收到响应，这时应用重新提交请求就导致服务重复调用，如果这个服务是一个转账操作，就会产生严重后果。

• 服务重复调用有时候是无法避免的，必须保证服务重复调用和调用一次产生的结果相同，即服务具有幂等性。有些服务天然具有幂等性，比如将用户性别设置为男性，不管设置多少次，结果都一样。但是对于交易等操作，问题就会比较复杂，需要通过交易编号等信息进行服务调用有效性校验，只有有效的操作才继续执行。

• 事务补偿

• 传统事务的 ACID

• 原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation，又称独立性）、持久性（Durability）

• 分布式事务的 BASE

• 基本可用（Basic Availability ）、软状态（Soft-state）、最终一致性（Eventual consistency）

• 事务补偿：通过执行业务逻辑逆操作，使事务回滚到事务前状态

• 重试

• 远程服务可能会由于线程阻塞、垃圾回收或者网络抖动，而无法及时返还响应，调用者可以通过重试的方式修复单次调用的故障。

• 上游调用者超时时间要大于下游调用者超时时间之和。

• 熔断

• 当某个服务出现故障，响应延迟或者失败率增加，继续调用这个服务会导致调用者请求阻塞，资源消耗增加，进而出现服务级联失效，这种情况下使用断路器阻断对故障服务的调用。

• 断路器三种状态：关闭，打开，半开

• 限流

• 在高并发场景下，如果系统的访问量超过了系统的承受能力，可以通过限流对系统进行保护。限流是指对进入系统的用户请求进行流量限制，如果访问量超过了系统的最大处理能力，就会丢弃一部分的用户请求，保证整个系统可用，保证大部分用户是可以访问系统的。这样虽然有一部分用户的请求被丢弃，产生了部分不可用，但还是好过整个系统崩溃，所有的用户都不可用要好。

• 限流的几种算法

• 计数器算法（固定窗口，滑动窗口）

• 固定窗口：使用计数器在周期内累加访问次数，当达到设定的限流值时，触发限流策略。下一个周期开始时，进行清零，重新计数。

• 滑动窗口：将时间周期分为 N 个小周期，分别记录每个小周期内访问次数，并且根据时间滑动删除过期的小周期。

• 令牌桶算法

• 以固定的速度向令牌桶中增加令牌，直到令牌桶满，请求到达时向令牌桶请求令牌，如获取到令牌则通过请求，否则触发限流策略

• 漏桶算法

• 访问请求到达时直接放入漏桶，如当前容量已达到限流值，则进行丢弃。漏桶以固定的速率进行释放访问请求，直到漏桶为空。

• 自适应限流

• 没有提前的人工评估， 便没有提前的评估过时与人的评估疏漏/错误!

• 实时自动评估 QPS

• 业务流量的不确定性与技术方案的自适应性天生一对!

• 降级

• 有一些系统功能是非核心的，但是它也给系统产生了非常大的压力，比如说在电商系统中有确认收货这个功能，即便我们不去确认收货，系统也会超时自动确认收货。

• 但实际上确认收货这个操作是一个非常重的操作，因为它会对数据库产生很大的压力：它要进行更改订单状态，完成支付确认，并进行评价等一系列操作。如果在系统高并发的时候去完成这些操作，那么会对系统雪上加霜，使系统的处理能力更加恶化。

• 解决办法就是在系统高并发的时候，比如说像淘宝双 11 的时候，当天可能整天系统都处于一种极限的高并发访问压力之下，这时候就可以将确认收货、评价这些非核心的功能关闭，将宝贵的系统资源留下来，给正在购物的人，让他们去完成交易。

• 异地多活

• 如果整个数据中心都不可用，比如说数据中心所在城市遭遇了地震，机房遭遇了火灾或者停电，这样的话，不管我们的设计和系统多么的高可用，系统依然是不可用的。

• 为了解决这个问题，同时也为了提高系统的处理能力和改善用户体验，很多大型互联网应用都采用了异地多活的多机房架构策略，也就是说将数据中心分布在多个不同地点的机房里，这些机房都可以对外提供服务，用户可以连接任何一个机房进行访问，这样每个机房都可以提供完整的系统服务，即使某一个机房不可使用，系统也不会宕机，依然保持可用。

• 异地多活的难点是数据一致。

11.6 高可用：架构运维方案

• 发布

网站需要保证 7×24 高可用运行，同时网站又需要不断的发布新功能吸引用户以保证在激烈的市场竞争中获得成功。许多大型网站每周都需要发布一到两次，而中小型网站则更加频繁，一些处于快速发展期的网站甚至每天发布十几次。

不管发布的新功能是修改了一个按钮的布局还是增加一个核心交易功能，都需要在服务器上关闭原有的应用，然后重新部署启动新的应用，整个过程还要求不影响用户的使用。这相当于是要求给飞行中的飞机换个引擎，既不能让飞机有剧烈的晃动，也不能让飞机降落，更不能让飞机坠毁。

既然网站的发布过程事实上和服务器宕机效果相当，那么就可以用服务器宕机的高可用方案来应对网站的发布。所以设计一个网站的高可用架构的时候，需要考虑的服务器宕机概率不是物理上的每年一两次，而是事实上的每周一两次。也许你认为这个应用不重要，重启也非常快，用户可以忍受每年一到两次的宕机故障，因而不需要复杂的高可用设计。事实上，由于应用的不断发布，用户需要面对的是每周一到两次的宕机故障。

• 自动化测试

代码在发布到线上服务器之前需要进行严格的测试。即使每次发布的新功能都是在原有系统功能上的小幅增加，但是为了保证系统没有引入未预料的 BUG，网站测试还是需要对整个网站功能进行全面的回归测试。此外还需要测试各种浏览器的兼容性，在发布频繁的网站应用中，如果使用人工来进行，成本和时间都难以承受。

目前大部分网站都采用 Web 自动化测试技术，使用自动测试工具或脚本完成测试。比较流行的 Web 自动化测试工具是 ThoughtWorks 开发的 Selenium。Selenium 运行在浏览器中，模拟用户操作进行测试，因此 Selenium 可以同时完成 Web 功能测试和浏览器兼容测试。

• 自动化部署

• 持续部署三步走

• 持续集成

• 允许工程师随时向公共分支提交代码，并立即进行自动化测试。

• 持续交付

• 除了跑单元测试及软件打包，持续交付机制会将软件部署到各种测试环境中

• 持续部署

• 代码在没有人工干预的情况下被测试、构建、部署并推送到生产环境。

• 持续部署流程

• 预发布验证

• 即使是经过严格的测试，软件部署到线上服务器之后还是经常会出现各种问题，甚至根本无法启动服务器。主要原因是测试环境和线上环境并不相同，特别是应用需要依赖的其他服务，如数据库，缓存、公用业务服务等，以及一些第三方服务，如电信短信网关、银行网银接口等。也许是接口变化导致的通信失败；也许是配置错误导致连接失败；也许依赖的服务在线上环境还没有准备好；这些问题都有可能导致应用故障。

• 因此在网站发布的时候，并不是把测试通过的代码包直接发布到线上服务器，而是先发布到预发布机器上，开发工程师和测试工程师在预发布服务器上进行预发布验证，执行一两个典型的业务流程，确认系统没有问题后才正式发布。

• 预发布服务器是一种特殊用途的服务器，它和线上的正式服务器唯一的不同就是没有配置在负载均衡服务器上，外部用户无法访问。

• 代码版本控制

• 主干开发、分支发布：

• 代码修改都在主干上进行，需要发布的时候，从主干上拉一个分支发布，该分支即成为一个发布版本，如果该版本发现 Bug，继续在该分支上修改发布，并将修改合并（merge）回主干，直到下次主干发布。

• 分支开发，主干发布：

• 任何修改都不得在主干上直接进行，需要开发一个新功能或者修复一个 bug 的时候，从主干拉一个分支进行开发，开发完成测试通过后，合并回主干，然后从主干进行发布，主干上的代码永远是最新发布的版本。

• 自动化发布

• 灰度发布

• 应用发布完成功后，仍然可能会发现因为软件问题而引入的故障，这时候就需要做发布回滚，即卸载刚刚发布的软件，将上一个版本的软件包重新发布，使系统复原，消除故障。

• 大型网站的主要业务服务器集群规模非常庞大，比如 QQ 的服务器数量超过一万台。一旦发现故障，即使想要发布回滚也需要很长时间才能完成，只能眼睁睁看着故障时间在不断增加干着急。为了应付这种局面，大型网站会使用灰度发布模式，将集群服务器分成若干部分，每天只发布一部分服务器，观察运行稳定没有故障，第二天继续发布一部分服务器，持续几天的时间才把整个集群全部发布完毕，期间如果发现问题，就只需要回滚已发布的一部分服务器即可。

• 网站运行监控

“不允许没有监控的系统上线”，这是许多网站架构师在做项目上线评审的时候常说的一句话。网站运行监控对于网站运维和架构设计优化至关重要，没有监控的网站，犹如盲人骑瞎马，夜半临深渊而不知。生死未卜，提高可用性、减少故障率就更无从做起了。

• 监控数据采集

• 用户行为日志收集

• 服务器性能监控

• 业务运行数据报告

• 监控管理

• 报警

• 自动控制

• 监控系统架构

• 高可用的价值观

• 保持简单，使问题易于发现，快速解决。

• 目标明确，解决特定环境下的具体问题。

• 价值回归，成本收益要合理。

11.7 高可用故障案例分析

• 故障 1

• 故障现象:

某应用服务器集群发布后不久就出现多台服务器相继报警，硬盘可用空间低于警戒值，并且很快有服务器宕机。登录到线上服务器，发现 log 文件夹里的文件迅速增加，不断消耗磁盘空间。

• 原因分析:

这是一个普通的应用服务器集群，不需要存储数据，因此服务器里配置的是一块 100GB 的小硬盘，安装完操作系统、Web 服务器、Java 虚拟机、应用程序后， 空闲空间只有几十 GB 了，正常情况下这些磁盘空间足够了，但是该应用的开发人员将 log 输出的 level 全局配置为 Debug。这样一次简单的 Web 请求就会产生大量的 log 文件输出， 在高并发的用户请求下，很快就消耗完不多的磁盘空间。

• 经验教训:

• 检查 log 配置文件，日志输出级别至少为 Warn，并且检查 log 输出代码调用，调用级别要符合其真实日志级别。

• 有些开源的第三方组件也会不恰当地输出太多的 Error 日志，需要关闭这些第三方库的日志输出，至于哪些第三方库有问题，只有在遇到问题时才知道。

• 应用程序自己的日志输出配置和第三方组件日志输出要分别配置。

• 故障 2

• 故障现象:

某应用发布后，数据库 Load 居高不下，远超过正常水平，持续报警。

• 原因分析:

检查数据库，发现报警是因为某条 SQL 引起的，这条 SQL 是一条简单的有索引的数据查询，不应该引发报警。继续检查，发现这条 SQL 执行频率非常高，远远超过正常水平。追查这条 SQL，发现被网站首页应用调用，首页是被访问最频繁的网页， 这条 SQL 被首页调用，也就被频繁执行了。

• 经验教训:

• 首页不应该访问数据库，首页需要的数据可以从缓存服务器或者搜索引擎服务器获取。

• 首页最好是静态的

• 故障 3

• 故障现象:

某应用服务器不定时地因为响应超时而报警，但是很快又超时解除，恢复正常，如此反复，让运维人员非常苦恼。

• 原因分析:

程序中某个单例对象（singleton object）中多个方法使用了 synchronized 修饰符， 由于 this 对象只有一个，即使执行不同方法，所有的并发请求也都要排队获得这唯一的一把锁。一般情况下，都是一些简单操作，获得锁，迅速完成操作，释放锁，不会引起线程排队。但是某个需要执行远程调用的方法也被加了 synchronized，这个方法只是偶尔会被执行，但是每次执行都需要较长的时间才能完成，这段时间锁被占用，所有的用户线程都要等待，响应超时，这个方法执行完后释放锁，其他线程迅速执行，超时解除。

• 经验教训:

• 使用锁操作要谨慎，特别注意在有锁的方法中进行长时间的 IO 操作的时候。

• 针对使用锁的不同场景，使用不同锁对象，而不是简单的在所有方法上都加上 synchronized

• 故障 4

• 故障现象:

没有新应用发布，用户并发请求也没有突然增加，但是数据库服务器突然 Load 飙升，并很快失去响应。DBA 将数据库访问切换到备机，Load 也很快飙升，并失去响应。最终引发网站全部瘫痪。

• 原因分析:

缓存服务器在网站服务器集群中的地位一直比较低，服务器配置和管理级别都比其他服务器要低一些。人们都认为缓存是改善性能的手段，丢失一些缓存也没什么问题，有时候关闭一两台缓存服务器也确实对应用没有明显影响，所以长期疏于管理缓存服务器。

结果这次一个缺乏经验的工程师关闭了缓存服务器集群中全部的几十台 Memcached 服务器，导致了网站全部瘫痪的重大事故。

• 经验教训:

• 当缓存已经不仅仅是改善性能，而是成为网站架构不可或缺的一部分时，对缓存的管理就需要提高到和其他服务器一样的级别。

• 故障 5

• 故障现象:

某应用发布后，服务器立即崩溃。

• 原因分析:

应用程序 Web 环境使用 Apache + JBoss 的模式，用户请求通过 Apache 转发到 JBoss。在发布时，Apache 和 JBoss 同时启动，由于 JBoss 启动时需要加载很多应用并初始化，花费时间较长，结果 JBoss 还没有完全启动，Apache 就已经启动完毕开始接收用户请求，大量请求阻塞在 JBoss 进程中，最终导致 JBoss 崩溃。除了这种 Apache 和 JBoss 启动不同步的情况，网站还有很多类似的场景，都需要后台服务准备好，前台应用才能启动，否则就会导致故障。

• 经验教训:

• 就本例来说，在 Java 应用程序中加入一个特定的动态页面（比如只返回 OK 两个字母），启动脚本先启动 JBoss，然后在脚本中不断用 curl 命令访问这个特定页面，直到收到 OK，才启动 Apache。

• 故障 6

• 故障现象:

某应用主要功能是管理用户图片，接到部分用户投诉，表示上传图片非常慢，原来只需要一两秒，现在需要几十秒，有时等半天结果浏览器显示服务器超时。

• 原因分析:

图片需要使用存储，最有可能出错的地方是存储服务器。检查存储服务器，发现大部分文件只有几百 K，而有几个文件非常大，有数百兆，读写这些大文件一次需要几十秒，这段时间，磁盘基本被这个文件操作独占，导致其他用户的文件操作缓慢。

• 经验教训:

• 存储的使用需要根据不同文件类型和用途进行管理，图片都是小文件，应该使用专用的存储服务器，不能和大文件共用存储。批处理用的大文件可以使用其他类型的分布式文件系统。

• 故障 7

• 故障现象:

监控发现某个时段内，某些应用突然变慢，内部网络访问延迟非常厉害。

• 原因分析:

检查发现，该时段内网卡流量也下降，但是没有找到原因。过了一阵子才知道，原来有工程师在线上生产环境进行性能压力测试，占用了大部分交换机带宽。

• 经验教训:

• 访问线上生产环境要规范，不小心就会导致大事故。

• 滥用生产环境的一个例子：网站数据库有专门的 DBA 维护，如果发现数据库存在错误记录，需要进行数据订正，必须走数据订正流程，申请 DBA 协助。于是就有工程师为避免麻烦，直接写一段数据库更新操作的代码，悄悄放到生产环境应用服务器上执行，神不知鬼不觉地订正了数据。但是如果不小心写错了 SQL，后果可想而知。

• 故障 8

• 故障现象:

某应用发布后，数据库 Load 迅速飙升，超过报警值，回滚发布后报警消除。

• 原因分析:

发现该应用发布后出现大量数据库读操作，而这些数据本来应该从分布式缓存读取。检查缓存，发现数据已经被缓存了。检查代码，发现访问缓存的那行代码被注释掉了。原来工程师在开发的时候，为了测试方便，特意注释掉读取缓存的代码，结果开发完成后忘记把注释去掉，直接提交到代码库被发布到线上环境。

• 经验教训:

• 代码提交前使用 diff 命令进行代码比较，确认没有提交不该提交的代码。

• 加强 code review，代码在正式提交前必须被至少一个其他工程师做过 code review，并且共同承担因代码引起的故障责任。

• 故障 9

• 故障现象:

某应用更新某功能后，有少量用户投诉无法正常访问该功能，一点击就显示出错信息。

• 原因分析:

分析这些用户，都是第一次使用该功能，检查代码，发现程序根据历史使用记录构造一个对象，如果该对象为 null，就会导致 NullPointException。

• 经验教训:

• 程序在处理一个输入的对象时，如果不能明确该对象是否为空，必须做空指针判断。

• 程序在调用其他方法时，输入的对象尽量保证不是 null，必要时构造空对象（使用空对象模式）。