写油猴脚本的传统艺能(Tampermonkey)- 教程

如果你在一家大公司工作,十有八九要面对百十个内部的所谓“自研系统”——大部分体验都非常拉跨。自研 SCM 的,自研 Ticket 系统的,自研文档系统的,还有一些很神奇的、搞不懂明明有很好的开源系统为啥不用偏要自研的系统。

不管出于什么原因,我们的大公司自研了这些系统,他们无一都有着一个共同点:体验很糟糕。包括:使用了先进的 SPA 技术但是 90% 的内部系统都没办法处理好 Url 的前进后退历史,翻页过滤等保持状态,甚至很多系统干脆就只有一个 URL: 比如 xdb.alipay.com…… 好吧,我猜这些都是专业团队开发的,专业领域比较强但是缺一个“专业前端”吧。

在这种环境中生存,尤其是作为一个“专业”的 SRE,我们就需要一些传统艺能:Python 爬虫,浏览器模拟器爬虫,油猴脚本。帮助你在各种险恶的内部系统中存活。

本文试图用 30 分钟(请现在开始计时)学会写油猴脚本,希望能在你快乐的 SRE 生涯中每天节约你几分钟的时间。

首先,先介绍下油猴脚本是什么(如果你真的不知道的话,我感谢你读到现在还没有走):油猴,Tampermonkey,是一个 Chrome 插件。我们都知道,JavaScript 本质上是客户端,就是运行在客户这边的软件。那么当客户这边的软件用着不爽的时候,客户是不是可以直接去修改软件呢?毕竟 JavaScript 也是脚本语言。当然可以!客户就是你,油猴就是帮助你修改 JavaScript 页面的软件。

油猴运行的方式是,你可以写一个 JavaScript 脚本,然后指定在什么 URL 运行,当你用浏览器打开这个 URL 的时候,油猴就会运行你的 JavaScript。这样,我们就可以把这些拉跨的网站变成我们想要的样子。

接下来我们安装油猴插件,Chrome 搜索安装即可。

安装好之后,我们来写你的第一个油猴脚本。

题目如下:你(其实是我自己)用 Roam Research 来记录工作笔记,你的公司用 JIRA 作为工单系统。每次你在处理一个工单的时候,你希望把这些过程都记录下来。比如你处理一个 URL 是 https://jira.mycompany.io/browse/IT-25582 的工单的时候,你想以下面的形式开始在 Roam Research 里面做记录: [[Ticket/IT-25582: Fix Alice's Computer]] ( https://jira.mycompany.io/browse/IT-25582 ) #IT #Computer #Alice。现在你是怎么做的呢?你要复制 Url,复制标题,复制工单编号,然后复制标签,最后在 Roam 里面打出来这句话。2分钟过去了……

所以我们希望能够一键做这个事情。效果是在“分享”按钮的后边会有一个一键复制的按钮,按下这个按钮,就会自动在你的剪切板插入这段格式的文本。然后你只要去 Roam 里面粘贴就可以了。

原理是:

  1. 从页面中使用 JavaScript 拿到标题,Url,标签等,拼出来要粘贴的内容
  2. 然后在页面上找一个合适的地方,加上我们的 Copy as Roam 的按钮
  3. 最后加一个监听的函数,这个按钮按一下,就把这段拼出来的文本放到剪切板里面去

首先,第一步,我们从页面找拿标题。这一步没什么难的,就是使用 JavaScript 的 API document.querySelector() 把想要的东西都拿出来即可。然后拼成一段文本。

然后,第二步,操作剪切板的函数(咦?不是加按钮吗?那太难了,待会在搞)。操作剪切板现在已经有 API 可以直接操作了。在这里我们需要搞一个假的 textArea, 然后把文字填进去,复制到剪切板。

最后一步,添加一个按钮。听起来这应嘎是最简单地一步,只要找到一个 Element 然后 Append 就好了,但确实最难的。因为现代网页用 JavaScript 太多了,你要找的 Element 也许根本就不存在。

解决方法是使用一个循环,延迟这个操作,一旦发现元素,则停止循环。

还有一个难点,因为 SPA 都是编译出来的,所以很可能整个网页都没有什么 id 可以用,如果有,它们的值也是每次编译自动生成的。这很头疼,我也没想到什么好办法,只能祝你好运了。

另外添加元素的时候,可以不比写自己的 CSS,直接 Copy 一下旁边的按钮的 class 用就好了,可以完美地混入其中。

油猴的原理大致就是这样,如果你要做的事情,八成就要去看浏览器提供了什么样的 API 了。大部分情况也不必自己从头开始写,一般有人做过类似的事情了,可以直接去搜索一下现成的脚本改一改。比如我这个教程,其实源代码就是抄了别人的。只不过我觉得他写的太繁琐了,就改了一些内容。

PS:量子幽灵 提醒我可以使用 MutationObserver 这个 API,这个 API 可以直接在某个 DOM 出现的时候去调用一个回调函数。

 

完整的脚本如下,贴在这里也没法直接用,但是相似的事情可以基于这个改一改。

 

如何杀死一个进程?

我们最近在实践 Chaos Engineering,而实现的一个最简单的 Chaos,就是 kill 一个进程。即使是这么一个简单的 Chaos 实验,我也遇到不少有意思的问题,这里记录一下。

首先介绍一个 trick,我们在 Linux 上查找进程的时候,一般会使用 ps -ef | grep nginx ,但是这样一般会在结果中得到两个进程,一个是找到的进程,另一个是 grep 本身。

那么怎么让 grep 不要出现在结果中呢?

比较简单的一种方法是,再 grep 一次就可以啦: ps -ef | grep nginx | grep -v grep 。高级一点的方法可以这样:ps -ef | grep [n]ginx 。原理是 grep 接收一个正则表达式,这样虽然最后还是 match 的 nginx 本身,但是我们运行的命令因为加了 [] 就不直接含有 nginx 这个字符串了。

但是如果要直接 kill 掉进程的话,大可不必先 grep 出来再执行 kill,直接使用 pkill 命令就可以了。

我用来测试的进程名字叫做 host-networking-manager,所以 pkill host-networking-manager ,但是返回的竟然是 1?没成功吗?看了一下,果然没成功,为什么?

最后折腾了一顿发现,pkill 其实是用 pgrep 去找到进程 kill 的。pgrep 找到目标进程是通过 /proc/[pid]/stat 文件。这个文件中的进程名字其实是只有 15个字符长度的。答案在 man 2 prctl 里面:

PR_SET_NAME (since Linux 2.6.9)

Set the name of the calling thread, using the value in the location pointed to by (char *) arg2. The name can be up to 16 bytes long, and should be null-terminated if it contains fewer bytes.

Linux 中的每一个进程都有一个 struct_task_struct 结构体,这个结构体定义在 include/linux/sched.h 里面。

这里面有一个字段 char_comm[TASK_COMM_LEN] 定义了可执行文件的,不包含 Path 的名字,最大长度是 16 bytes,除去最后一个留给 null 的,就只有最多 15 个字符。

可以打开 /proc 下的文件看一下:

所以说,正确 kill 这个进程的方式应该是 pkill host-networking 。

或者使用另一个方法,pkill -f host-networking-manager -f flag 会告诉 pkill 使用 /proc/pid/cmdline 这个文件来匹配进程。这个文件里面包含了进程启动的时候的完整命令,包括参数。(为什么这里我要高亮呢?请继续阅读……)

在尝试使用 -f 参数的时候,我遇到了一个诡异的现象。比如我使用我的 chaos 程序运行一个 yaml 定义的实验的时候。chaos run kill-host-networking-manager 我的实验自己会退出…… 从 log 的信息来看,它也收到了一个 kill 命令。

就在我百思不得其解这个 kill 信号是哪里来的时候,在高人的指点下,原来是我自己发的…… 当我使用 pkill -f host-networking-manager 的时候,由于执行这个命令的进程本身也有 host-networking-manager 这个名字(chaos run kill-host-networking-manager)所以它自己也会匹配上。相当于自己也会把自己杀掉!

那么为什么不使用 -f 参数就没有问题呢?因为在 /proc/pid/stat 文件中,我的父进程叫做 chaos 所以不必匹配到……

 

另外几种比较准确地根据一个名字杀掉进程的方法:

  1. 如果使用 systemd 启动的,可以使用这个命令查看 PID systemctl show –property MainPID <unitfile>.service
  2. pidof 命令也可以准确地找到进程的 PID。

以上 Tips 是 GrayCode 提供的。

 

接手一个新的项目,我会关注的3个问题

作为 SRE,在工作中,接手一个新项目是很平常的事情。离职、入职、组织结构调整等,都可能会让你来接手管理一个项目或者组件。在 take over 的时候,我总结了一些需要关注的重点问题。

1. Where did it deploy?

项目部署在哪里?这是最重要的一个问题。是直接部署在物理机上,还是部署在容器上?是用什么方案部署的,如果发布新的版本,发布的流程是怎么样的?

可以到机器上看下都有哪些进程在运行。如果是一个中间件,可以尝试使用这个中间件写一个小 demo 体验一下。

最好是能画出来部署的架构图。

2. How do we monitor?

当前的部署结构算是一个静态的,那么监控就相当于是一个动态的。

监控可以告诉你当前系统的请求量,系统的运行状态。以后的工作中可能打交道最多的也是监控了。所以学会看懂监控非常重要,需要针对当前的监控面板,问清楚每一个指标代表了什么。

然后,可以从项目所要解决的问题上,去评估,哪些指标可以告诉我们当前的服务状态,发现核心服务的状态需要哪些数据。从而也可以评估当前的监控是否完善。告警是否设置了,设置的是否合理。

3. Where is the code?

以前我可能会问:“这个项目的文档在哪里?”,但是我发现,文档要么是过时的,要么是一团糟,要么没有。但是软件要想跑起来,没有代码是不可能的,所以不如直接问一下代码在哪里?代码中什么都有。(当然,如果有文档更好)。

在开发者和 SRE 之间划一条线,代码的逻辑从不过问,遇到问题就找到开发者说“帮我看下这里问题出来哪里了?” 这样是做不好工作的。我认为一个合格的 SRE 首先要是一个好的程序员。

SRE 看代码可能更会专注于配置类,这个项目是如何连接数据库的,是如何发现其他的服务的,是如何部署在服务器上的,有哪些项目是可以配置的,配置是什么管理的。以及这个项目选择的一些依赖,用了什么开源项目。

如果不去做问题 3,那么了解部署结构、了解监控,也都是做不好的。很多工作只有清楚了代码的逻辑才能进行得更加深入。

如果有时间,多去看看项目的逻辑代码,也是挺有意思的。可以对比一下类似的产品的处理方式,也可以和同事互相学习,了解同事的品味。

 

交接的时候,主要的问题问清楚这些基本就可以了。然后先熟悉一段时间,再发现其中的问题,比如发布流程是否合理,有些运维工作是否能够自动化。慢慢地读代码,搞懂逻辑,再发现更多可以优化的事情。SRE 是和项目一起成长的。

 

React Hooks 基础教程

最近在写一个前端页面,看了一个 UI 框架的 Example,发现已经看不懂 React 了。上次写 React 的时候,还都是用 Class Based Component, 我还花了一些时间弄明白一个组件的“生命周期”,没想到这么短的时间,已经不流行使用 Class 写组件了。现在用一个叫 React Hooks 的东西,可以通过函数写出来组件。为了看懂现在的 React 代码,我又去学了 Hooks,这边文章来总结我对 Hooks 的理解。

Hooks 就是一些 React 提供的内置函数,通过 Hooks 就可以在 Function 中操作组件的状态(state)了。在我看来解决了两个问题:

  1. Function 中是不可以定义 state 的,所以以前 Function 只能用来写 stateless 的组件,如果有一天你觉得这个 stateless 的组件要加入状态了,那就必须把它先变成 Class Base Component 才行;
  2. Class 组件本身也有问题,它这个设计是要求开发者按照组件的生命周期来写代码,constructor() -> componentDidMount() -> componentWillUpdate() 这种方式,按照 React 的逻辑来组织代码,而不是按照代码本身表达的业务逻辑来组织代码。以前每次写一个新的组件的时候,我都要依靠 Vim 的模板功能生成一个代码模板,但是现在不需要了。写 Hooks 几乎没有模板代码。

通过例子认识 Hooks

下面这个例子来自官方的文档。

在这个例子中,使用 useState() ,让这个组件 “hook” 了一个 React 的 state:count 。count 的初始值就是 useState() 的参数,即0. 如果要改变 count 的值,就使用 setCount 这个函数。(之前是使用 this.setState() )。

可以这么理解,useState() 函数就关联了一个 React 的 state,调用 useState() 会给你 state 的应用,以及更新它的方法。(Hooks 都使用 “use” 开头,为什么不使用 “create” 呢?因为它只是和一个 state “关联”起来了,只是告诉 React “使用”这个 state。只有在组件第一次 render 的时候才会创建这个 state,在后续的更新中并不会创建了。)

另一个 React 提供的 hook 是 useEffect() 。如它的名字,这个 hook 不是和 state 有关的,而是产生 “effect” 的。类似于 React Class 中的 componentDidMount() 或者 componentWillUpdate() 中。

比如下面这段代码:

组件第一次更新的时候会调用 useEffect() 收到的函数,并且以后这个组件每次 render 的时候也会调用:更新页面的标题。

可以看到这里面没有和 React 组件生命周期相关的函数名字。这意味着我们可以根据业务逻辑来组织代码,可以将 effect state 等相关的逻辑放在一起,而不是把多个不相关的业务逻辑,都放到 componentDidMount() 里面去。

之前的这种按照组件生命周期来组织代码的方式,很容易出 Bug。比如,下面是一段正确的代码。这个组件订阅了朋友的在线状态,当组件 Unmount 的时候,会需要取消对这个朋友的状态订阅:

但其实 componentWillUnmount 这个函数非常容易忘记(尤其是在逻辑越来越多的情况下),造成内存泄漏。

如果用 useEffect() 来实现的话,就比较清晰了,因为这个函数接受的参数是 Effect 的函数,Effect 函数的返回值可以是一个 clean up 的函数。(好像比较绕,这个设计确实有些奇怪,为什么不将 clean up 的函数作为 useEffect 的第二个参数呢?)

useEffect() 来写的话,就是下面这种形式:

把更新的函数传给 useEffect() ,然后在自己的函数里面返回一个 callback 用来 cleanup. 因为这些逻辑都是在一起的,所以更加不容易忘记。

另外,useEffect() 会在组件 Mount 以及每次更新的时候都运行,相当于 componentDidMount() 和 componentWillMount() 两个函数合起来了。

Hooks 的原理

一个函数中可以使用 Hooks 多次,用来关联不同的 state,比如下面这段代码:

但是在调用 useState() 的时候并没有告诉 React name 是和哪一个 State 来关联,React 是怎么知道的呢?

答案是调用顺序,你按照这个顺序使用 Hooks,React 就按照这个顺序给你赋予这些 state 的值,“绑定”的过程类似下面这样:

所以顺序至关重要,知道这一点,就可以避免一些错误的使用方法。比如,一个原则是,只在 Component 的最顶层使用 Hooks,假如你没有函数的最顶层使用 Hooks,而是在嵌套结构(比如循环或者 if block 中)使用,那么绑定的时候就会出问题。

比如像下面这样:

那在 React 实际绑定组件的内部状态的时候,就会乱掉:

另一个原则是,只在 React Function Components 里面使用 Hooks。如果只在 Function Component 里面调用 Hooks 的话,你看到一个 Component 就会知道里面的 State 的变化,但是如果状态还在 Component 外面被控制,那么就很难管理了。并且 React Hooks 应该也不会在 Component 之外去帮你管理这些状态。

定义自己的 Hooks

没有 Hooks 以前,如果要抽象一部分涉及 state 的代码出来复用的话,只能再写一个 Class Component,现在可以用 Hooks 了。我们可以定义一个自己的 Hook。

比如,重用一段 Friend 订阅上下线的逻辑:

Hooks 里面会调用其他的 Hook,当然,也只能在最顶层来调用

我们自己定义的 Hooks 不像是 React 内置的那些一样参数都是固定的,Hooks 本质上就是调用了其他的 Hooks 的函数,所以我们可以自定义自己的参数和返回值:

  • 订阅一个朋友的状态:所以接收的参数是 FriendId
  • 提供的是朋友的状态,所以返回一个 onlineStatus

在 React 的视角,即使你 call 的是你自己定义的 Hooks,但是最终里面,还是调用的 React 定义的 Hooks。所以最终,你都只调用了 React 提供的 Hooks。就像我们所有的程序调用的函数最终只调用到了系统提供给我们的函数一样。

参考资料:

  1. https://reactjs.org/docs/hooks-intro.html
 

2020年的总结

2020年对于地球来说是不平凡的一年。年初爆发了 COVID-19 病毒,全球基本上就处于了封锁的状态。紧接着之后又发生了很多不好的事情,这些都可以从维基百科查到,我就不用来占用这篇博客的字数了。

年初我和欣和大多数人一样,居家隔离。每天就是在晚上订菜,做饭,在家办公。谁能想到,2020年的最后一天,我现在在赤道附近30多度的天气里面写这篇年终的总结。

说起总结,今年好像没有什么好总结的。一切都过得非常平凡,甚至可以说有一些碌碌无为。只有一两件事情可以说说。

第一件,我结婚了。这件事情可以让 2020 年成为我人生的一个分割线。从今年起,我就不再是一个人了。剩下的人生可以有一个人一起走完。

第二件,就是离开了阿里巴巴。其实在刚开始加入阿里巴巴的时候,我就觉得这家公司不适合我。但是又说不上是哪里的问题,我到底想要什么。这几年就试图找到自己想要的东西。

在这个博客的草稿箱躺着一篇文章,计划着离职之后发出来。(一家公司的员工只有在离职之后才能说话,这是一个悲哀)。以为我在离职的时候会有什么轰轰烈烈的原因,其实并没有。想明白了自己想要什么,就离开了。非常简单和平静。以至于这篇文章现在看来都没有发布的必要,写完之后就删掉了。

其实面试一直是在进行中的。只要一家公司做的事情以及对待员工不是特别地没有道德,我一般都会参加面试。通过面试过程再决定要不要加入。所以可以说是一个双向选择的过程。我觉得即使最后没有通过面试或者拒绝offer,但是通过面试的过程也可以学到东西,和面试官交流经验。

因为知道选择一份不适合自己的工作会有多大的损失,所以对于下一份工作的选择特别谨慎。我非常喜欢 SRE 的工作,我觉得 SRE 的工作有意义要满足一个必要的条件:SRE 的数量不能随着业务的数量增长,SRE 必须以固定的成本支撑增长的业务。不然的话,就和传统的运维没有本质的区别。我现在的公司的 SRE 数量已经超过了 500 人。以及我经常会问面试官一个问题:您是如何看到 AIOps 的?因为这个问题的答案能反映出我对这家公司(至少是 SRE 团队)的理念是否符合。

今年去面试过的公司有 LeanCloud,今日头条,PingCAP,Shopee。拿到 Offer 的公司有 LeanCloud,今日头条,PingCAP,Shopee。

我觉得 LeanCloud,PingCAP 这两家公司非常值得说一说。我怕很多人不知道中国存在这样优秀的公司,所以在这里打一个广告。

LeanCloud 可以说是中国版的小规模版 Heroku,我没有想到员工数量会这么少,这么少的人做出这样的产品,至少可以说明这里面每一个人都是精英。并且 LeanCloud 有一些理念非常地超前。感兴趣的可以看下他们的公开资料: 开放薪资,以及江宏老师的博客。技术上的选型也比较极客,用的 Clojure, nodejs 等。

PingCAP 是一家做数据库的中国公司,在开源方面做的很好。TiDB 是一个可以水平扩展的数据库,这几年在国内技术上和业务上发展的都很好。现在有很多公司在使用 TiDB 了,比如 Shopee,知乎,一些银行等。除了 TiDB,他们还开源了很多优秀的项目,比如 chaos-mesh等。如果没有开源的基因,这些事无法做的的。PingCAP 不像阿里巴巴做的是弃婴式开源,是真的开源。技术上依然比较极客,非常 Cloud Native,语言主要是 Rust/Go。SRE 团队在做的事情也非常有意思。

最后我选择加入 Shopee。其实最根本的原因,还是现阶段的 Shopee 能满足现阶段的我吧。一个12人的 SRE 团队,负责了从网络到文件系统到存储,到 CMDB 等非常广的方面,需要做的事情有很多,这样让我感到很兴奋:)相比之前的工作,基本上什么事情都有非常多的人在做,之前的事情虽然做过了但并不能说完善,只能说能用的状态。然后大家都不喜欢维护老旧的系统,喜欢在这些系统上包一层或将之进行取代,做出花来,以便晋升。所以我觉得现在的 SRE 团队更加踏实一些。

以上提到的所有公司,如果读者有兴趣,都可以找我内推。但是希望读者最好是对 Shopee 有兴趣。

有关于2020年,其他的事情倒是没有什么好提起的了。我觉得我在 2020 年浪费了很多时间在开会,对着奇怪的设计思考为什么要这个样子,试试证明只是因为组织的架构问题罢了,其实更简单的方案就摆在那里。但总体来说,这也是一段非常宝贵的工作经验吧。至少今年我花了很多时间来思考我要什么,我想成为什么样子的人,我的梦想。

2021年,就继续朝着这个方向努力吧。


往年:

  1. 2013年
  2. 2014年
  3. 2015年
  4. 2016年
  5. 2017年
  6. 2018年
  7. 2019年