昨天下午 15:00，我们发现了 CI 的大规模异常，基本上就是 connection failed 和 Could not resolve host 的连环轰炸。
在查找问题之前，先来看看从我们伪 DevOps 能治理的角度出发可能是什么问题，一个运行中的 CI 任务到底是跑在哪里的：
在我们这里，CI 机器是有一个独立网段的，部署一个 CI 需要若干台机器，由 Master 负责调度给 Slave，Slave 在机器上创建新的 Docker 容器运行任务。
本文目标人群：自己，请勿期待
之前在 NAS 里搭建了一整套 dev 环境（大概），但是由于希捷两块硬盘双双 GG，我实在没有办法——所以就寄回去换了硬盘，顺便跟老板说换成西数的吧，没想到真的帮我换了，加上在京东买的西数金盘和东芝的企业盘，换了老价钱换上了 RAID 10. 再把内存加到了 8G，完全体建立完毕。
一般来说，我这里的基础设施得益于 CDN、OSS 和网关层，到了这里都不用扛太多的流量，只要写的不怎么车祸，后端都不存在什么性能瓶颈。
但是这次要上一个灰度功能，需要和业务相结合，在此之前我们的灰度都是以 DNS 为标准进行地区式的灰度，但是现在流量必须要直接打到后端才能判断，如果前面缓存了就没办法灰度了——因此没办法，我们只能船到桥头自然直——扛吧。
先来简单描述一下我们的代码逻辑：查询 1 -> 处理逻辑 -> 查询 2 -> 查询 3 -> 处理逻辑 -> 灰度判断 -> 返回。
最初保持了最原始的代码，没有设置任何缓存，这在过去是满足需求的，因为缓存是由网关层的反向代理帮我们在 Header 里加上的，包括了 s-max-age 和 max-age。
今天在公司看到了一个同事的演讲总结，觉得其实自己也应该总结一下。
目前自己参加过四次演讲，一共是：
之前经常有用户反馈我们做的系统中，在上传过程中会遇到 Request body larger than maxBodyLength limit，其实这个问题之前已经存在了很久，但是一直没去动。
最初以为是服务端发出的 error，因为默认使用的 koa-body 在旧版本也有上传内容的大小限制，但是后来调试过程中发现请求根本没发出去——
今天同事向我反馈，当我们的静态资源有中文名混杂 + 和空格 时，得到的链接并不能打开，返回的是 404.
举个例子，假定我们的资源为：
http://example-resource.oss-cn-shanghai.aliyuncs.com/23232323/中文 + 文件-file.ec296f20-d67b-11e8-a623-7b28809dc3c9.js那么在浏览器中访问的文件名应该被转义为：
%E4%B8%AD%E6%96%87%20+%20%E6%96%87%E4%BB%B6-file.ec296f20-d67b-11e8-a623-7b28809dc3c9.js注意，在这里，空格被转义为 %20，而 + 没有进行任何处理。
之前遇到了在一段提示中需要加粗的问题，我们都知道，加粗有几种写法：
<b><strong>但是，这三者到底有什么区别——
在大多数场景下，我都会选择使用 font-weight，众所周知的是，HTML 应该与语义结合，如果是一般的加粗，那么使用 font-weight 刚刚好。
从开搞到文章结束过了一个月……所以……看看就行
前两天在一个群里看到一个问题，有人问「yarn 能不能人工锁版本号」，刚开始我们都没有理解，觉得明明直接用 yarn 或者 yarn install 就能生成 lock 文件，为什么要人工生成。
于是被介绍了一个 npm shrinkwrap，这是在 package-lock 出现之前就有的项目依赖锁定工具，实际上效果和 package-lock 差不多，唯一的不同是：npm shrinkwrap 是手动生成的。同样的，在更新包、删除包时也需要在完成后手动使用 npm shrinkwrap。
在现代的版本中，如果两者同时存在，那么会优先取 shrinkwrap：
This command installs a package, and any packages that it depends on. If the package has a package-lock or shrinkwrap file, the installation of dependencies will be driven by that, with an npm-shrinkwrap.json taking precedence if both files exist. See package-lock.json and npm-shrinkwrap.
由于 Time Machine 先后救我于水火之中两次，但是我的路由器实在不方便做，仗着有一点微小的闲钱（2000 块……），我就开始研究 NAS 了。
在购买之前，首先先查了一波 NAS 的户口：群晖、威联通、玩客云——玩客云首先由于功能薄弱先 Pass，与其说玩客，不如说是视频+，具体是在什么值得买看到的……Emmmm，一点都不 Server。
威联通的价格比群晖低好多，不过相对的软件生态也不太一样，刚开始苏老师跟我疯狂案例威联通，看了一下价格还算可以，同样的价格群晖的配置比威联通低一点，而且还只有两个盘位，隔壁威联通能买到四个盘位，配置可扩展性也更高一点——但是在 DIY 的黑群的对比下，完全是碾压级别的……便宜。
最近在写项目的时候有个需求：我的 Promise 即使失败了也没关系——更进一步的，当且仅当失败率大于某一值，这才是一个失败的请求。
于是我查看了包括 ES6 Promise 和 Bluebird 的实现，发现都没有我想要的效果：
在完成项目之后把函数抽出来作为一个单独的 utils 模块发布，今天总算把 lint 和 test 补齐了，于是顺手写一篇宣传文。
他没什么大作用，函数实现还是表现形式都比较 Low：
const foreach = require('sky-promise-foreach')
foreach([...promises], (result) => {
// success handler for each promise
}, (err) => {
// error handler for each promise
})在同事的建议下，之后有空可能会出一个改版，把这个库做的更通用一点。