部署失误事件发生在上周三(16/10/12)，每周四发布新版本是我们技术团队的开发节奏，测试环境部署、安装、试用一切顺利，正是这样的常规顺利麻痹了自己，在正式环境服务器、iOS、Android 代码自动部署更新后，只是使用手头的 iPhone 简单测试了一下，而没有通知相关同事进行批量、全面的测试，可笑的是问题就发生在正式环境 Android 应用上。
先简单说下原因，再慢慢回忆常规部署流程中的不足及隐患。客户端测试、正式环境都是使用 HTTP 访问服务器 API, 但为了安全起见，正式环境服务器域名部署了沃通的 SSL 服务即支持 HTTPS 访问。为了让正式环境的 HTTP 链接都能自动跳转到 HTTPS 链接，就修改 nginx 配置 80 端口 (HTTP) redirect_to 443 端口 (HTTPS), 在浏览器中测试发现 javascript/css 等静态资源无法获取成功，因为浏览器不支持跟踪跳转，于是静态资源都是 301 状态。定位到问题所在，很容易找到解决方案：判断 HTTP 链接后缀为静态资源类型时直接访问即可。部署失误的原因就是在这一点上，客户端添加了 API 下载报表数据 zip 压缩包，不符合上述 nginx 直接访问的条件，于是 Android 应用下载报表数据都是 301 状态，导致所有报表都无法正常展示。
再简单描述下项目，属于企业级的迭代开发，即产品开发完成核心功能后就上线，后面的功能是边开发边上线。客户未全面内部推广，每日使用人数稳定在 300-500，为了每次在正式环境部署避免失误，就部署了与正式环境服务器、客户端相同的测试环境，测试环境服务器配置了二级子域名（仅支持 HTTP 访问），常规服务器代码部署、客户端发布都使用脚本完成，所以每周四的更新都未出现问题，对正式环境部署的紧张压力慢慢淡去，直到上周的黑色周三（下午部署，晚上爆发）。
客户在微信开发跟进交流群中反馈，一时没有反应过来，客户强调只有正式环境中的 Android 应用有问题，测试环境的 Android 应该是正常的，更是让人一头雾水，打开 Terminal 登录服务器后台查看日志，一切访问正常，是哪里出了问题呢？当时怎么也没有联想到正式环境中 nginx 修改了配置会自动 80 端口转 443 端口，手头也没有 Android 测试机，模拟器运行也正常（事后反省，认真查看模拟器 console 是可以发现问题的），直到第二天，同事发现报表数据下载时服务器响应 301，才醍醐灌顶，了然于心。把下载报表数据的 API 链接在 nginx 配置中修改为直接访问，正式环境的 Android 应用于是像虾池中张雅吴昭夫妇般温顺。
HTTP to HTTPS
在 nginx 端处理 HTTP 自动跳转 HTTPS 更多的是吃力不讨好，只有填不完的坑，不如各司其职。如果想在浏览器中给客户友好的一片绿色环保，在网页中使用 javascript 跳转更为合理，比如百度，其实百度仅域名首页访问处理的就比较复杂，为了拿到下述代码非一试就成:
$ curl -A 'Mozilla/5.0 (iPhone; CPU iPhone OS 9_1 like Mac OS X) AppleWebKit/601.1.46 (KHTML, like Gecko) Version/9.0 Mobile/13B143 Safari/601.1' HTTP://www.baidu.com
<!DOCTYPE html>
<html>
<head>
<title></title>
<meta name="referrer" content="never"/>
</head>
<body>
<script type="text/javascript">
function qs(n, m, v, u) {
u = u || D.URL;
var t = u.match(eval('/(\\?|#|&)(' + n + ')=([^&]*)(&|$)/i'));
if (t) {
m = m || t[2];
v = t[3] || v
}
return m && v ? '&' + m + '=' + v: ''
}
function fc() {
var h = location.host,
x = '=;expires=' + new Date(0).toUTCString(),
y = x + ';path=',
z = y + '/;domain=',
l = [x, y, y + '/', z + h, z + h.substr(h.indexOf('.'))],
o = D.cookie.match(/[^ =;]+(?=\=)/g);
if (o && S) for (var i = o.length; i--;) for (var j = 5; j--;) D.cookie = o[i] + l[j];
if (window.localStorage) localStorage.clear();
if (window.sessionStorage) sessionStorage.clear();
setTimeout(fc, 500)
}
function fj() {
var u = ('https://m.baidu.com/?' + (D.URL.match(/pu=sz(%|@)d+_d+/i) || [''])[0] + '&from=1012883x').replace(/(\?|#)&/g, '$1');
if (navigator.userAgent.match(/webkit/i)) D.body.appendChild(D.createElement('iframe')).src = 'javascript:parent.location.replace(\'' + encodeURI(u) + '\')';
else D.write('<meta HTTP-equiv=\'Refresh\'content=\'0;Url=' + u + '\'/>');
D.close()
}
var D = document,
d = D,
S = !D.cookie.match(/home=s/i);
D.body.style.visibility = 'hidden';
D.oncontextmenu = function() {
return false
};
fc();
fj()
</script>
</body>
</html>
/*
* fj() 函数中的 if else 本质都在实现跳转 HTTPs.
*/
客户端的逻辑就更简单，想更安全就直接使用 HTTPS, iOS 开发者都知道 ATS(App Transport Security) 即使用最新 TLS1.2 版本的 HTTPS, 从 17 年开始苹果审核团队会将 ATS 作为强制审核项。但服务器的 SSL 服务是按年购买，目前由我来运维，之后未可知，就当前阶段而言，应用的用户体验高于一切，就果断放弃客户端通过 HTTPS 访问服务器 API。
在 nginx 端实现所有 HTTP 跳转 HTTPS，安全性、多坑暂且不论，需要 HTTP、HTTPS 两次域名解析，更耗时是肯定的。
通过这次失误，引起很多反省: 注意事项需写入文档，部署前对比检查；日常工作的注意事项与同事多交流，在出问题时大家才能一起检查可能原因；多学习别人的经验分享、最佳实践方案，这样的经验文章，网上肯定很多；最重要的一点，一定要测试每一个环节，这是最后的一道防线。
