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

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

201706/stock-exchange.png

目的 🎯

我们先来聊聊,什么是「监控」,以及我们期望通过「监控」完成哪些目的?

传统意义上的监控,是指:

通过一些手段和工具,关注运行中的硬件、软件、用户体验的关键数据,将其暴露出来。 当关键数据出现异常时候发出警告,进行人工或者自动的响应。

我们平时看到的最常见的监控系统,比如 Zabbix,提供了丰富的模板, 可以监控服务器的 Load / CPU Usage / Alive 这些常规指标。 并在出现问题时候,对其进行报警通知。 随后运维工程师们会上线进行应急操作,case by case 的处理故障。

我将上面的使用目的归纳为:

  • 故障发生时提供数据报警
  • 提供历史数据以供分析

故事到这里似乎可以结束了,可监控真的是这么简单的么? 当然没,随着时代的进步,用户对服务提出了更为严苛的要求 …

more ...

XSS 攻击的处理

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

201705/wooyun.jpg


事情缘由

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

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

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

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

more ...

👁️ 预测未来?

拉普拉斯之妖

未来是可以被预测的么?

201702/zhu-ge-liang.jpg

专家在预测股票趋势变化,天气预报员可以预测未来一周甚至更长时间的天气。 如果给他们更多的信息和参数,是否可以将未来预测的更准确? 如果精确的粒度可以达到基本粒子级别,同时给一个计算力超群的计算器,能否精确的推衍未来变化?

这些想法在我刚接触经典力学时浮现,学习了牛顿三定律之后,异常激动。 感觉人类可以凭借技术的进步,逐步对未来精确预测。彼时可以解决人类即将遇到的任何问题了,化问题于无形。

这想法其实在 200 年前就出现了。法国伟大的数学家拉普拉斯(Laplace)在他的著作「概率论」里面, 提出了这样的观点:

我们可以把宇宙现在的状态视为其过去的果以及未来的因。假若一位智者会知道在某一时刻所有促使自然运动的力和所有组构自然的物体的位置,假若他也能够对这些数据进行分析,则在宇宙里,从最大的物体到最小的粒子,它们的运动都包含在一条简单公式里。对于这位智者来说,没有任何事物会是含糊的,并且未来只会像过去般出现在他眼前。

「根据当前已知即可预测未来」,这种决定论,就是拉普拉斯之妖。

打破

除了拉普拉斯的决定论,这个世纪末还发生了另外一件事情。 开尔文男爵在 19 世纪的最后一天,发表了「物理大厦已经落成,所剩只是一些装饰性工作」的言论。 然而,在随后的岁月里,经典物理大厦却开始被量子力学逐步击破 …

more ...

👷如何做年前大扫除

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

我们称之为年前大扫除。

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

201701/saber.jpeg

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

大扫除的内容

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

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

more ...

🔑 也谈 HTTPS - 如何内测

201612/mouse.jpeg (图片来自 茶杯中的可爱小白鼠 壁纸 - 2560x1920-堆糖,美好生活研究所)

在上篇文章 🔒 也谈 HTTPS - HTTPDNS + HTTPS 中, 我们谈了如何基于 HTTPDNS 来部署无坚不摧的 HTTPS 通信环境, 这次我们讨论另外一个比较头疼的问题:部署。

小站点部署 HTTPS 相对成本低,改改前端代码,就可以上线了。 但作为业务有一定复杂度的大网站,就没办法这么暴力上线了。

前端在基础库中调整 Scheme 之后,仍然可能存在很多边边角角没有覆盖到。 比如 JS 里面写死了 HTTP,那在 HTTPS 下请求 HTTP XHR 的话, 浏览器会将请求拦截掉。 一旦出现这种故障,用户就无法正常使用业务,小白用户往往也不懂得自己将 https:// 换成 http:// 使用。

解决的思路是足够的内测,找一群人帮我在 …

more ...

教你在上海挑房子

201612/shanghai.jpg

点开的同学别失望,这并不是教你如何快速致富的 😂 ……


上海政府在 11-28 出了房屋新政 via,对房价进行进一步调控。 其核心思想是「认房又认贷」。3 月份的政策 via 是限制购房资格。 这次 11 月份调整则是提高二套房首付比例。 双管齐下,进一步给上海房市进行降温。

在这种严苛的政策下面,如何挑选一套自己满意,家人住得安心的房子就尤为关键了。 我对房市一直比较关注,也曾有几位朋友咨询我的一些经验。之前我是将 Evernote 笔记链接贴给别人,这次我就详细讲讲,如何在上海挑房子。

第一步,是建立有价值的 Indicator,并对具体房源进行计算。 Indicator 的含义是建立一系列评价指标,比如价格、户型、位置, 再根据这些 Indicator 给房源进行打分。 如果我是一个购房者,我挺希望我的置业顾问告诉我这套房有哪些优点、缺点,综合评价得几份。 (当然实际情况下这些置业顾问都是吹得天花乱坠,尽睁眼说瞎话。) 看房的过程可能长达数月,而人的记忆会随着时间逐步失真,只对最近看到的事物有深刻印象。 使用客观的数字评价房源 …

more ...

🔒 也谈 HTTPS - HTTPDNS + HTTPS

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

201611/https.png

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

尽管使用了 HTTPS 技术,部分邪恶的运营商,仍然使用 DNS 污染技术,让域名指向的他们自己服务器 而这些服务器并没有部署 SSL 服务(就算部署了,也会触发 SSL 证书 …

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 的最大课题。 在这里有最常用的两个手段,一个是优化性能,一个是做好容量规划和扩展。 这里我着重讨论后者「容量规划」。

看我的一堆报警消息

^ 看我的一堆报警消息

面临的问题

面对暴涨流量,一边是业务方的满心欢喜,一边就是工程师的烦恼和压力了。 也许是一个受欢迎的功能上线了,或者是某个社会活动导致流量爆发,系统开始出现高延迟,磁盘 IO 不够用了。 也许是 DB 第一个倒下,也许是 RPC 系统第一个倒下…… 呃 …

more ...

一次「分答」记录

尝试在团队内部发起一次类似「分答」的沟通方式,一对一面聊。 回答其他工程师的问题,这种沟通的方式暨在提供一个特定的场合,帮助加强双方了解, 解决团队中其他工程师的一些实际的问题。

在征得对方同意之后,我将他的问题和我的回答 PO 出来。

201606/questions-and-answers.jpg

  1. 喜欢什么游戏,玩游戏的问题
    • 喜欢和人玩游戏,不喜欢和不认识网友玩游戏
    • 小学从红月开始玩,传奇、CS、魔兽、真三、DOTA,大学时候和舍友玩游戏,毕业后不玩
    • minecraft 尝试着玩过,没有玩下去,找不到人
    • 日活的桌面游戏,三国杀等蛮喜欢
    • 不喜欢浪费时间,怕没控制
    • 从玩游戏里面学习什么么?不,就是纯粹享受游戏,不会想这么多
  2. 喜欢什么语言
    • 看场合,小东西,小场景用 Python,生产环境用 Java,生产环境又有时间,考虑 Scala
    • 只允许选一门语言,就用 Python
    • 最吸引的特点 …
more ...