如何杀死一个进程?

我们最近在实践 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年
 

Devops 中的 Overfitting

在运维工作中,很多人都在宣扬自动化,经过几年的工作,我发现这种自动化在某些地方有些极端了。devops 崇尚自动化,但并不是一味的自动化。有一些事情是适合手工操作的,过度的自动化会浪费跟多的成本,只能得到很少的收益。

就好像一台电梯,用古老的电梯算法运行了很久,但是有一天有人觉得这个电梯运载能力没有发挥到极致,我们可以使用机器学习训练他采用更好的算法。于是就需要更多的人力资源来实现这个项目:一个小组提供训练数据,一个小组来训练新的算法模型,设计一套硬件设施监控和对比运载效率,设计回归的方案评估运载效率的变化,等等……

最终可能发现将原来两台电梯的运载能力变成了相当于2.5台的运载能力,但是这优化出来的0.5台电梯带来的问题有:1)某些情况下的表现可能还不如电梯算法 2)没有人知道现在电梯是怎么运行的了,因为这是机器学习训练出来的模型 3)复杂的算法从上线走向成熟需要持续的维护和优化,稳定性不如原来的电梯算法。等等。其结果还不如就再增加一台电梯。(当然,也可能因为当初楼里的设计结构不允许再增加电梯,软件工作中也有类似的问题。)

最近又看到一个例子:

牙膏厂生产流程会产出没放牙膏的空箱。厂长花8百万请专业顾问,用牛逼的秤测箱子重量,发现空箱就警报并停止流水线,员工手动除空箱。后来秤再也检测不到空箱了,为何?员工自动化了除空箱的步骤:用20元的风扇吹。

source

(这个例子被指出只是一个段子,详见这里。2022年3月更新)

我同意《Google SRE 运维解密》中提到的一个观点:应该尽量避免黑魔法系统。但是“魔法”在大公司中好像非常受追捧。因为将原来人工操作的东西,变成自动化的东西,这对于赢得年终奖、晋升来说,太有说服力了。用20元的风扇吹,这么简单的方案,如何能体现出来你的工作价值,展现你的能力呢?

在很多时候,这种“过度的”自动化,只会产生一些只针对特定场景、特定的 Case 才能发挥出一点作用。我觉得这就是一种 Overfitting。比如很多公司都在做的故障自动定位系统,有一种做法是,当一个故障发生之后,SRE 去写一堆 if-else,实现如下的效果:只有仅当系统 A 出现 X 错误,并且系统 B 执行了 Y 操作的时候,这个故障定位系统能够将问题的根因准确无误的报告出来。但是一模一样的错误,在一个复杂的分布式系统中重新出现一次的概率,又有多少呢?这么做的意义,最多只不过是给领导一个交代罢了:看,虽然这次故障造成了损失,但是如果相同的故障再发生,我们花几分钟就可以恢复了。

之前看到一个从蚂蚁金服的 SRE 离职的员工在博客里失望的说:系统应该是自治的,而不是自动化的。因为是在 CSDN 上看见的,现在找不到原文了。我非常同意他的话。对于自治,我是这么理解的:分布式系统本身应该有一定的错误恢复能力,类似于 Redis Cluster 的 Fail Over. 而不是依靠外部的一些系统去自动化(依赖 if-else 逻辑)判断监控数据或者状态,进行自愈之类的操作。

就像是智能手机出现之前,大部分的黑白屏手机都有一个功能叫做情景模式:选择一个情景模式,就会附带给你设置好铃声、震动、短信提示等。但是我从没见过周围有人使用这个功能。iPhone 出来之后,将提示音的设置做成了一个物理按键,你不再需要记住那么多情景模式下都是什么设置,只有一个按钮,关上之后不会发出声音,就这么简单。我们搞的那些黑魔法系统,背后设置了那么多东西,却无法告诉用户我们到底做了什么,这只会让SRE的心理负担越来越重。(另一个想说的点是,我实际上认为,当前公司的可用性有很大一部分是建立在对员工的心理负担上面的。如果造成P1故障,全年3.25取消年终奖。就算更改一行代码,要经过至少40min,还有层层审批,才能发布。等等)

其实编程中也存在这种 overfitting,和 devops 一个道理,大量的if-else嵌套会让你看不出到底是哪一些逻辑在执行。这会造成代码异常复杂并且难以维护。

想起来 Linus 在谈到代码品味时说的:

对我来说,我愿意与之共事的人, 必须有好的品位,这就是如何…… 我举的这个例子很傻, 没什么意义,因为实在太短。 好的品位体现在更长的代码里。 好的品位体现在能看清全局 甚至有一种直觉, 知道怎么把事情做漂亮。

简单即是美,Unix 提倡每一个工具都做一件事情,这样用户可以将它们自由地组合在一起,完成复杂的任务。但是现在好像大家导出都喜欢做“平台”,喜欢将能想到的所有的东西都涵盖进来,所谓“远大的视角”。我认为作为 SRE,了解所要维护的系统的原理,它是怎么运行的,做好监控,远比去做一些魔法系统收益要大。

一个 SRE 团队中,这种有“品味”的人至关重要。太多的 Overfitting 会将整个团队带向一个无限复杂度的深渊,在这样一条路上无论如何挣扎、怎样加班,最后都会冲下去。

ML for Systems 我感觉在现在业界的情况来看就是伪命题,坑贼深.

–By 某推友