当我们在聊监控,我们在聊什么?

最近在团队中给大家做了一个分享,泛泛地聊了一些有关「监控」的话题。 其实做分享对分享者的作用往往大于参与者。 这是一次将自己知识的梳理的过程,于是我将这次分享整理成这篇文章。

201706/stock-exchange.png

more ...

XSS 攻击的处理

这是一年前写的项目笔记,一直在我的待办事项里等待做总结,今天偶然翻到,就整理成文章发出来。 谨以此文怀念 乌云

201705/wooyun.jpg


事情缘由

春节前的某一天,收到一封来自乌云(国内知名白帽子团队)的邮件, 告知我厂网站上出现一例 XSS 漏洞。 因为以前对 XSS 输入做过防御,还以为是某个前端 DOM 上的 XSS 漏洞, 后来仔细一看,不妙,是个影响甚大的存储型 XSS 漏洞。

这里简单科普一下 XSS 跨网站脚本 -维基百科,自由的百科全书 中介绍到:

跨网站脚本(Cross-site scripting,通常简称为XSS或跨站脚本或跨站脚本攻击)是一种网站应用程序的安全漏洞攻击,是代码注入的一种。 它允许恶意用户将代码注入到网页上,其他用户在观看网页时就会受到影响。这类攻击通常包含了HTML以及用户端脚本语言。

XSS 攻击可以分成两种,反射性 XSS / 存储型 XSS。前者是需要用户触发的 XSS ...

more ...

👷如何做年前大扫除

今年过年特别早,离春节只剩下二十多天了。 为期 7 天的春节里,工程师们不上班,那万一线上业务出现了故障怎么办? 大公司的朋友们会安排专门的人进行值班(此处心疼一下那些需要大年三十还要值班保证高峰的工程师们), 而作为创业团队人少,难做到在线值守,就需要对线上进行一些整理盘点,找出潜在问题,为春节长假做一些准备。

我们称之为年前大扫除。

大扫除需要做些什么呢,且听我一一道来。

201701/saber.jpeg

PS: 冷知识,大扫除英文是 spring cleaning,所以春节大扫除是 Spring Festival spring cleaning。

大扫除的内容

大扫除其实是一个查漏补缺+囤积粮草的事情。

查漏补缺,即找出潜在的问题。这些问题平时可能不会特意去查看, 借助大扫除这个运动,恰好进行盘点。 计算机的世界里,有一个方法论非常好使,在极多场景可以见到其身影:分层。 TCP 的七层模型,架构设计的 N 层 模型,都是对分层思想的使用。 查漏补缺也不例外,我们可以按照业务访问流程,将需要排查的问题拆分为:业务 ...

more ...


🔒 也谈 HTTPS - HTTPDNS + HTTPS

最近谈论 HTTPS 的文章很多,其原因之一是运营商作恶底线越来越低,动不动就插播广告, 前两天小米还联合几家公司发文 关于抵制流量劫持等违法行为的联合声明 痛斥某些运营商。 另一方面也是苹果 ATS 政策的大力推动,逼迫大家在 APP 中全部使用 HTTPS 通信。 上 HTTPS 的好处很多:保护用户的数据不外泄,避免中间人篡改数据, 对企业信息进行鉴权。

201611/https.png

关于 HTTPS 如何购买证书,如何部署,网上的教程已经太多了,实践起来没有太大的难处。 我们在部署 HTTPS 的时候,遇到了一些新问题,首当其冲的就是 HTTPS 部分网络不可访问的问题:

尽管使用了 HTTPS 技术,部分邪恶的运营商,仍然使用 DNS 污染技术,让域名指向的他们自己服务器 而这些服务器并没有部署 SSL 服务(就算部署了,也会触发 SSL 证书 Common name 不一致报警), 导致 443 端口直接被拒绝。

more ...

API 集成测试实践

abao.png

为了提高测试,工程师需要对自己提交的产物进行测试,一般是单元测试、集成测试。 之后提交物流转到 QA 团队,QA 团队根据需求描述对提交物进行测试, 这个测试过程非常耗费人力。 尤其是当开发交付的质量不高时候,很可能自身没有经过测试,会遇到主干流程都无法进行的状况。

如果在 QA 人工介入测试之前,就进行一轮黑盒自动化集成测试,可以大大地提高 QA 团队的工作效率。 基于这样的判断,我们团队花了一些时间,将基于 API 的自动化测试系统搭建起来。 现在将这个系统的选型和运行状况拎出来,和大家分享。

确认测试范围、目标和意义

  • 范围
    • 后台输出的 API 级别 URL
    • 使用场景
      • 打包时候的冒烟
      • Dev / QA 手工添加添加新特性用例
  • 目标
    • 覆盖大部分的 URL,当期设计为 top 10 URL,仅包含 GET 接口
    • 选型时 ...
more ...

搞定暴涨的流量

2013 年左右,我司业务发展迅速,每天晚上都会面临服务器濒临崩溃情况。 我相信每个高速发展的互联网企业在某个阶段都会面临这样的情形,比如去年爆红的「足迹」。 过程往往是:线上出现故障,手机会收到报警,然后登录到服务器上去解决问题。 处理这种问题工种现在有一个时髦的名称,叫做「SRE(Site Reliability Engineer)」系统可用性工程师。

虽然我常常救火,但是我还是想尽可能避免线上发生故障。「最好的消息,就是没有消息。」 减少故障出现概率,增强系统可用性,降低故障处理时间是 SRE 的最大课题。 在这里有最常用的两个手段,一个是优化性能,一个是做好容量规划和扩展。 这里我着重讨论后者「容量规划」。

看我的一堆报警消息

^ 看我的一堆报警消息

more ...

一例 Timeout 故障

i_love_timeouts_digital_design_mugs.jpg

早晨刚到公司, HAProxy 报警,Trtornis(第三方云存储网关,用来统一管理阿里云和七牛云的对象存储) 全飘红。

more ...

怎么打日志

logger

需要解决的问题:

  • 业务日志打太乱,没有位置和格式约束
  • 什么情况打日志,如何避免滥用,提高日志作用

打日志最佳实践

Dropwizard 列出的打日志原则:

Be human readable.

Be machine parsable.

Be easy for sleepy ops folks to figure out why things are pear-shaped at 3:30AM using standard UNIXy tools like tail and grep.

eg.:

TRACE [2010-04-06 06:42:35,271] com.example ...
more ...

Redis 集群扩容

几乎每一个网站都需要用户登录状态系统,其中核心是存储 Session 的用户登录状态存储系统。 主流的实现之一是使用 Redis 存储用户登录信息,Redis 特点是功能简单、无依赖、 存储结构丰富、有持久化功能。 我大堆糖的 Session 存储系统也正是基于 Redis。

可是 Redis 也存在一些问题,比如 Redis 自身没有 Sharding 功能,Replication 也是在逐步完善完善过程中 (2.4 支持 Replication,2.8 加入 Replication partial resynchronization 功能)。 纵观当下流行的 DB 系统,哪个不是自带这两个特性,这两个分布式特性应该成为新出产的 DB 系统的标配。 而且作者还经常发布延期,放烟雾弹,不知道 Redis 自带 Sharding ...

more ...