某局点的ats经常出现HIT/502的故障，客户一旦发飙，这是个扯不清的问题，如果是MISS/502那可以说是源站错误，但HIT/502就与ats业务系统有关系了。经过手动测试，同一个url直接回源连续访..
某局点的ats经常出现HIT/502的故障，客户一旦发飙，这是个扯不清的问题，如果是MISS/502那可以说是源站错误，但HIT/502就与ats业务系统有关系了。
经过手动测试，同一个url直接回源连续访问，偶尔就有502，问题很明显了，源站是不稳定的。分析后发现源站使用某厂家的CDN做的分发，造成了源站不稳定，我们拿到的是CDN的内容，而且返回的502信息中还有明确的max-age，ats按照max-age的信息把故障信息存下来了，真是害死人的节奏。
ats对于故障信息是有配置参数的，我们已经对没有max-age头的故障信息设置为不缓存，有max-age头故障信息是要看情况缓存的，因为有可能碰到源站改版等问题，也就是说有些故障信息是有必要缓存的。
经过研究，发现header头重写可以解决这个故障，思路就是劫持399到599状态码的响应header头，强行将cache-control标记删除，同时加上Cache-Control no-cache，那样的话故障信息就不会存储了，我们就在线上测试，又发现配置后只对新的请求生效，对老的信息是不起作用的，一查缓存，5.7T的存储已经写满，不敢轻易操作了，后想办法配置缓存规则，采用保守的方式将5.7T的信息通过7天的刷新，502/HIT彻底解决，把header头的操作分享出来，供大家一起研究。
header_rewrite.so是ats编译时自带的模块，只是默认没有打开，所以需要在ats里注册添加，然后编写规则，header模块注册方法是：
在plugin.config 中加入:
header_rewrite.so header.config，指定了header的配置文件是header.config
然后就是在header.config中添加规则，添加如下（测试的时候又发现带max-age的故障信息是不好伪造的，没折又想了对正常信息进行测试来看功能是否可行，走了一些弯路）：
cond %{STATUS} >399 [AND]
cond %{STATUS} <599
rm-header Cache-Control
add-header Cache-Control no-cache 添加好后重新加载配置文件traffic_line -x
对于刷新资源，ats默认带了对单条url强制刷新的规则，不过不适合我们当前的场景，于是利用cache.config编写缓存规则，让资源的保鲜期设置为5分钟刷新一次，ims缓存规则的设置就不多介绍了，之前有写。
“运维网咖社”原创作品，允许转载，转载时请务必以超链接形式标明文章 原始出处 、作者信息和本声明。否则将追究法律责任。http://www.net-add.com
 |
社长"矢量比特"，曾就职中软、新浪，现任职小米，致力于DevOps运维体系的探索和运维技术的研究实践. |
