本文首发在沪江技术学院公众号，小莞翻译，我做了校对。 由于微信公众号的封闭性，我担心未来文章不容易被发现。 为了避免沧海遗珠，特意转到这里。 英文原文：The USE Method。 USE 方法是一种能分析任何系统性能的方法论。 我们可以根据能帮助系统分析的结构化清单，来迅速的定位资源的瓶颈和错误所在。 它通常会先以列出问题为开始，然后再寻找适合的指标，而不是给你制定一些固定的指标， 然后让你按部就班的执行下去。 本页左侧下方，是我列出的，根据不同的操作系统（Linux、 Solaris 等） 衍生的 USE 方法列表。（译者注：可以参考原文链接） ...
原文作者：Nick Craver 翻译作者：罗晟 @luosheng & @alswl 原文地址：Nick Craver - HTTPS on Stack Overflow: The End of a Long Road 本文为原创翻译文章，已经获得原作者授权，转载请注明作者及出处。 本文首发在「沪江技术学院」公众号 今天，我们默认在 Stack Overflow 上部署了 HTTPS。目前所有的流量都将跳转到 https:// 上。与此同时，Google 链接也会在接下去的几周内更改。启用的过程本身只是举手之劳，但在此之前我们却花了好几年的时间。到目前为止，HTTPS 在我们所有的 Q&A 网站上都默认启用了。 ...
加入沪江不久，我就被扔到一个将集团 SQL Sever 的数据库迁移到 MySQL 的项目里， 同时伴随进行的还有 .net 系统迁移到 Java 系统。 在这个过程中我发现了一个很有趣的现象：历史遗留的 .net 项目中， 几乎所有的 SQL 中都会使用一个关键字：nolock。 这让我很困惑，nolock 的字面意思是对当前技术不使用锁技术，为什么要这样用呢？ 我找了一个范例如下： SELECT [id] FROM [dbo].[foos] WITH(nolock) WHERE aField = 42 AND bField = 1 作为横向支持工程师，开发工程师会问我：「数据库即将从 SQL Server 迁移到 MySQL，我们编码中还需要使用 nolock 么？ MySQL 里面对应的写法是什么？」。 我并没有 SQL Server 的生产环境使用经验，一时间无法回答。 于是课后做相关知识学习，这里就是这次学习的一点成果。 ...
最近在团队中给大家做了一个分享，泛泛地聊了一些有关「监控」的话题。 其实做分享对分享者的作用往往大于参与者。 这是一次将自己知识的梳理的过程，于是我将这次分享整理成这篇文章。 目的 🎯 我们先来聊聊，什么是「监控」，以及我们期望通过「监控」完成哪些目的？ 传统意义上的监控，是指： 通过一些手段和工具，关注运行中的硬件、软件、用户体验的关键数据，将其暴露出来。 当关键数据出现异常时候发出警告，进行人工或者自动的响应。 ...
这是一年前写的项目笔记，一直在我的待办事项里等待做总结，今天偶然翻到，就整理成文章发出来。 谨以此文怀念 乌云。 事情缘由 春节前的某一天，收到一封来自乌云（国内知名白帽子团队）的邮件， 告知我厂网站上出现一例 XSS 漏洞。 因为以前对 XSS 输入做过防御，还以为是某个前端 DOM 上的 XSS 漏洞， 后来仔细一看，不妙，是个影响甚大的存储型 XSS 漏洞。 这里简单科普一下 XSS 跨网站脚本 -维基百科，自由的百科全书 中介绍到： 跨网站脚本（Cross-site scripting，通常简称为XSS或跨站脚本或跨站脚本攻击）是一种网站应用程序的安全漏洞攻击，是代码注入的一种。 它允许恶意用户将代码注入到网页上，其他用户在观看网页时就会受到影响。这类攻击通常包含了HTML以及用户端脚本语言。 XSS 攻击可以分成两种，反射性 XSS / 存储型 XSS。前者是需要用户触发的 XSS， 针对当前用户的攻击行为。而后者存储型 XSS 则更为严重，一旦攻击代码被保存， 所有访问被攻击的页面，都会触发用户被攻击行为。 这次爆出的问题就是最严重的存储型 XSS，意味着每个访问到有问题页面的用户都会中招。 时间紧迫，问题必须被解决。 XSS 实现手段 在解决问题之前，需要对这个问题有必要的基础认识。 我们先看看 XSS 攻击是如何工作的，以及攻击者的目的是什么。 XSS 的原理是通过构造特殊的数据，并通过传递参数或者保存表单数据的方式， 让这些构建的数据破坏 DOM 结构，从而让自己预先构造数据中的 JS 脚本被执行。 检查存储型 XSS 漏洞的方法，可以在对应的 input field 里放入一些构造的数据，如果保存后可以被执行，就说明存在 XSS 漏洞。 常见的检测方法（来自 跨网站脚本 - 维基百科，自由的百科全书： ><script>alert(document.cookie)</script> ='><script>alert(document.cookie)</script> "><script>alert(document.cookie)</script> <script>alert(document.cookie)</script> <script>alert (vulnerable)</script> %3Cscript%3Ealert('XSS')%3C/script%3E <script>alert('XSS')</script> <img src="javascript:alert('XSS')"> <img src="http://xxx.com/yyy.png" onerror="alert('XSS')"> （这个仅限IE有效） 攻击者通过 XSS 可以窃取用户的相关信息，如果用户是管理员，那么影响更大。 通过这些身份信息，攻击者可以进一步篡改信息或者进行诈骗，后果不堪设想。 PS：一个有效粗暴的方式，是将对公、对内系统的域名分离，对内部系统进行物理级别隔离。 我厂历史上的处理方案 XSS 问题又来已久，咱厂子开了这么久，历史上如何防御的呢？ 答案是用了两个策略：第一个是使用 OWASP 提供的库进行内容过滤，第二个是在存储数据时，存储了转义后的数据。 在技术上处理 XSS，有两种态度可以选择：第一种是前置过滤，即将用户所有数据都进行转义， 在输出时候在前端（模板渲染）层面直接输出。 第二种是用户输入的数据不经过转义就直接存储起来，前端在使用时候保证对数据进行转义。 我厂历史上使用的方案的前者，优点是在于前端不需要在每个地方转义， 避免某个地方忘记了转义，从而导致漏洞。缺点则是在输出内容到非 Web 客户端时候，比如 APP，需要进行额外的数据处理过程， 否则 HTMLEncode 的内容，在 APP 上面无法正确输出。 这个处理方案是稳妥的，那么为什么最近又暴露出问题了？ 排查之后发现，原来最近有若干个服务迁移到了一个新系统， 而新系统在安全上面没有全局处理，所以爆出了漏洞。 本次处理方案 知道了原因，那么可以快速解决问题了。在这次处理过程中，我们讨论了在当前移动平台增长迅速，Web 平台增长缓慢的大势下，能否直接存储用户原始数据？ 而且由于规范制定不严格，目前系统内有些地方存储转码后数据，有些地方存储转码前数据。 导致在一些特殊的字符（颜文字）处理上不一致，从而导致在处理 br / < 这类特殊字符时，表现不同。 由于 DB 中有部分数据转义处理，部分数据原文存储，所以先处理输出后敏感信息，在模板层面启用全局 encode。 将有危险的数据转移为在 HTML 文本。 PS：现代 Web 框架的模板渲染引擎，一般会默认开启 HTMLEncode，而 Freemarker 居然在 2.3.24-rc01 才支持，现在都没有发布，唉…… 处理方案： 开启全局 HTML 输出 Encode，有一个 Default HTML-escape using Freemarker 方案，可以默认开启 Html Encode，在这个处理方案中，需要注意有些地方真的需要输出原始 html，需要 noescape 特殊处理 检查所有前端操作，禁止字符串拼接，使用框架支持的模板进行渲染，拖小菊的福，新系统在这块工作完成度一直比较好 将 OWASP 方案强制开启 其他 Tips OWASP 有一个很长的 列表，教导如何避免 XSS，里面提到了： 为何以及如何进行「积极防御」，对立面是仅仅输出时候转义内容本身 几条对抗 XSS 的规则 尽量不在特定地方输出不可信变量：script / comment / attribute / tag / style， 因为逃脱 HTMl 规则的字符串太多了。 将不可信变量输出到 div / body / attribute / javascript tag / style 之前，对 & < > " ' / 进行转义 将不可信变量输出 URL 参数之前，进行 URLEncode 使用合适的 HTML 过滤库进行过滤 预防 DOM-based XSS，见 DOM based XSS Prevention Cheat Sheet 开启 HTTPOnly cookie，让浏览器接触不到 cookie 最后送上一个 XSS 攻击工具 http://webxss.net/，知己知彼，百战不殆。
今年过年特别早，离春节只剩下二十多天了。 为期 7 天的春节里，工程师们不上班，那万一线上业务出现了故障怎么办？ 大公司的朋友们会安排专门的人进行值班（此处心疼一下那些需要大年三十还要值班保证高峰的工程师们）， 而作为创业团队人少，难做到在线值守，就需要对线上进行一些整理盘点，找出潜在问题，为春节长假做一些准备。 我们称之为年前大扫除。 大扫除需要做些什么呢，且听我一一道来。 PS: 冷知识，大扫除英文是 spring cleaning，所以春节大扫除是 Spring Festival spring cleaning。 ...
(图片来自 茶杯中的可爱小白鼠 壁纸 - 2560x1920－堆糖，美好生活研究所) 在上篇文章 🔒 也谈 HTTPS - HTTPDNS + HTTPS 中， 我们谈了如何基于 HTTPDNS 来部署无坚不摧的 HTTPS 通信环境， 这次我们讨论另外一个比较头疼的问题：部署。 小站点部署 HTTPS 相对成本低，改改前端代码，就可以上线了。 但作为业务有一定复杂度的大网站，就没办法这么暴力上线了。 前端在基础库中调整 Scheme 之后，仍然可能存在很多边边角角没有覆盖到。 比如 JS 里面写死了 HTTP，那在 HTTPS 下请求 HTTP XHR 的话， 浏览器会将请求拦截掉。 一旦出现这种故障，用户就无法正常使用业务，小白用户往往也不懂得自己将 https:// 换成 http:// 使用。 ...
最近谈论 HTTPS 的文章很多，其原因之一是运营商作恶底线越来越低，动不动就插播广告， 前两天小米还联合几家公司发文 关于抵制流量劫持等违法行为的联合声明 痛斥某些运营商。 另一方面也是苹果 ATS 政策的大力推动，逼迫大家在 APP 中全部使用 HTTPS 通信。 上 HTTPS 的好处很多：保护用户的数据不外泄，避免中间人篡改数据， 对企业信息进行鉴权。 关于 HTTPS 如何购买证书，如何部署，网上的教程已经太多了，实践起来没有太大的难处。 我们在部署 HTTPS 的时候，遇到了一些新问题，首当其冲的就是 HTTPS 部分网络不可访问的问题： ...
为了提高测试，工程师需要对自己提交的产物进行测试，一般是单元测试、集成测试。 之后提交物流转到 QA 团队，QA 团队根据需求描述对提交物进行测试， 这个测试过程非常耗费人力。 尤其是当开发交付的质量不高时候，很可能自身没有经过测试，会遇到主干流程都无法进行的状况。 如果在 QA 人工介入测试之前，就进行一轮黑盒自动化集成测试，可以大大地提高 QA 团队的工作效率。 基于这样的判断，我们团队花了一些时间，将基于 API 的自动化测试系统搭建起来。 现在将这个系统的选型和运行状况拎出来，和大家分享。 确认测试范围、目标和意义 范围 后台输出的 API 级别 URL 使用场景 打包时候的冒烟 Dev / QA 手工添加添加新特性用例 目标 覆盖大部分的 URL，当期设计为 top 10 URL，仅包含 GET 接口 选型时，需要考虑非幂等（POST / DELETE / PUT）等接口 意义 提高开发效率，一种自动化的 IT 测试方案 提高测试效率，减少人工集成测试成本 提高工程质量，通过覆盖率提升，保证工程质量逐步提升，放心开发新功能 特性需求 选型一个系统，不是看市面上有哪些可以供选择，而是看我需要什么样特性的一款产品。 如果自己的需求和市面上的现成产品差异过大，也可以考虑自己定制。 Required 开源 免费 使用 DSL 或者简单代码描述测试用例 支持细粒度的单 API 测试和构建带过程的测试用例 HTTP API Optional CI 集成 UI 挑选出来的选型和评价 API Monitoring and Testing · Runscope 收费 非开源 有监控特性 Bamboo - Continuous integration, deployment & release management | Atlassian 收费 CI Continuous Integration Product and Features - CircleCI CI 收费 Sauce Labs 客户端测试，收费 Apiary API 设计工具 + API Test http://frisbyjs.com/ code npm open source NO UI https://github.com/vowsjs/api-easy 同上 真是热爱造轮子的 JS 生态圈 https://github.com/visionmedia/supertest 同上 从 Star 看，这个质量最高 http://dareid.github.io/chakram/ code npm open source NO UI https://vrest.io/ 收费 不开源 无插件 http://swagger.io/open-source-integrations/ for API 生态环境强大 https://github.com/cachecontrol/hippie-swagger 用户端似乎在尝试用 swagger http://robotframework.org/ 一个通用自动化测试工具 DSL 扩展性较强 活跃度在降低 https://github.com/robotframework/robotframework/graphs/contributors https://cucumber.io/ https://cucumber.io/docs/reference 和 Robotframework 相似，通用自动化测试工具 DSL 活跃度降低 https://github.com/cucumber/cucumber-jvm/graphs/contributors https://www.solanolabs.com/ Airbnb 在用 收费 云端的通用测试环境 https://github.com/christophd/citrus http://www.citrusframework.org/ 依赖 mvn / ant，离代码太近 项目不够活跃 代码内测试 src/it/com/duitang/xxx eg. tritornis Spring http://docs.spring.io/spring/docs/current/spring-framework-reference/html/integration-testing.html http://docs.spring.io/autorepo/docs/spring-framework/3.2.x/spring-framework-reference/html/testing.html 这部分工作，是和团队的其他成员一起去看的，大家各自分头寻找一些产品，然后进行评测，给出结论。 经过讨论，我们将重点关注放在这么几款下面： supertest robotframework swagger 讨论时候的新发现 https://github.com/svanoort/pyresttest 搭建 demo，进行试用 在确定选用那几款产品之后，就可以集中精力在几款候选者里面。搭建相应的环境，对他们进行实际测试。 supertest： 功能太简单了，简单到几乎可以自己写掉，不算一个 test framework pyresttest： 哈哈哈，YAML based，dreamed feature 支持 YAML / extractor / validator 天生支持 host 为参数 create for me!!! hippie-swagger： 在使用上，和 supertest 差异不大 仍然需要自己定义，在 swagger 描述文件不存在时候会抛错，描述文件不符合时会抛错 robotframework： 较为复杂 有 YAML 了，不用试了 使用感觉 经过一个季度的试用，我们基于 pyresttest 的项目 abao 运行较稳定。 尽量在工程师提交代码之后，运行一次，从而可以在早期发现问题。 由于是基于 Python 的源代码，我们还给 pyresttest 开发了几款插件： cookie_extractor：用来解析特定的 cookie file_choice_generator：从文件随机选择预设数据 file_seq_generator：从文件顺序选择预设数据 在和 CI 的配合方面，我们在 Jinkins 搭建了 abao / abao-master 项目， 前者响应每次 Push 请求，都会自动构建一遍，后者每天凌晨会将 master 运行一遍。 感谢项目贡献者： project : abao repo age : 5 months active : 32 days commits : 109 authors : 39 Chery.Peng 35.8% 33 3D 30.3% 17 yanqi.chen 15.6% 11 橙子 10.1% 7 fiona66 6.4% 2 雪糕 1.8% 参考文档 ...
2013 年左右，我司业务发展迅速，每天晚上都会面临服务器濒临崩溃情况。 我相信每个高速发展的互联网企业在某个阶段都会面临这样的情形，比如去年爆红的「足迹」。 过程往往是：线上出现故障，手机会收到报警，然后登录到服务器上去解决问题。 处理这种问题工种现在有一个时髦的名称，叫做「SRE（Site Reliability Engineer）」系统可用性工程师。 虽然我常常救火，但是我还是想尽可能避免线上发生故障。「最好的消息，就是没有消息。」 减少故障出现概率，增强系统可用性，降低故障处理时间是 SRE 的最大课题。 在这里有最常用的两个手段，一个是优化性能，一个是做好容量规划和扩展。 这里我着重讨论后者「容量规划」。 ...